Thanks Mark, Will try to take a peak. Regards, Jaunius Kapkan [Sent from cellphone]
On 2020-03-04, at 07:08, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Jaunius,
I don’t know of any automatic facility to do this. A counter/timer to be used in the case of a can bus message setting setpoint to zero makes sense as a workaround.
However, it is probably worth looking elsewhere in that CAN bus message to see if there is any flag that changes to indicate the value is stale. You can get a CAN bus dump of this message, along with the one for CC on/off, and see if there is any correlation.
Regards, Mark.
On 4 Mar 2020, at 3:06 AM, Jaunius K. <jaunius@gmx.com> wrote:
Hi Mark,
Thanks again for the tip, however it seems that the 0 is sent just before the CC is turned off. So to avoid that I guess I need to set a delay to update the metric each n seconds to give enough time for the CC to go in to OFF state.
Is there any built in way of doing that, or do I have to add my own function?
Currently that code part looks like this:
// setpoint gets reset on CC off, so we only update it while it can be actually changed if (StandardMetrics.ms_v_env_heating->AsBool() || StandardMetrics.ms_v_env_cooling->AsBool()) { float setpoint_float = d[4] / 2; m_climate_setpoint->SetValue(setpoint_float); } Regards, Jaunius
On 2020-02-14 11:11, Mark Webb-Johnson wrote:
The ’stale’ system simply sets a flag on the metric - it doesn’t modify the metric value at all.
Auto-stale works by having a timer that is reset every time the metric is updated. If the timer expires then the metric is automatically marked as stale.
So, to se a metric to zero value, you must have some code that explicitly does that. Maybe when the climate control is turned off it sends zero values for set point on the can bus? In the Tesla Roadster code, I have specific code to ignore temperature updates when aux12v (used to be ‘awake’) is off - as I know the updates are not real, and I want the metric to go stale.
Regards, Mark
On 14 Feb 2020, at 7:33 AM, Jaunius Kapkan <jaunius@gmx.com> wrote:
Hi,
Let me come back to this topic. I have re-made the metrics somewhat accoding to your recomendations, but I am having an issue with the setpoint value: OVMS# metrics list v.e.cab v.e.cabin.fan 6 v.e.cabin.fanlimit 7 v.e.cabin.intake recirc v.e.cabin.setpoint 28°C v.e.cabin.vent screen|feet v.e.cabintemp 0°C OVMS# metrics list v.e.cab v.e.cabin.fan 0 v.e.cabin.fanlimit 7 v.e.cabin.intake unknown v.e.cabin.setpoint 0°C v.e.cabin.vent off v.e.cabintemp 0.5°C
bascailly as soon as climate control is truned off this value goes back to default. Should I use a different STALE parameter?
m_climate_setpoint = MyMetrics.InitFloat("v.e.cabin.setpoint", SM_STALE_NONE, 0, Celcius);
Regards, Jaunius
Sent: Monday, November 11, 2019 at 7:51 AM From: "Mark Webb-Johnson" <mark@webb-johnson.net> To: "OVMS Developers" <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] Nissan LEAF: HVAC Metrics
I will look into this, and let you know. The fan speeds, etc, can normally be represented as a percentage of maximum (to make it easier for Apps).
Can you explain what your car offers, and what the proposed settings are:
v.e.cabin.fan 0-100% (cabin fan speed) v.e.cabin.setpoint 999C (cabin temperature set point) v.e.cabin.intake fresh/recirc (cabin air intake mode) v.e.cabin.vent feet | face | screen (or comma-separated list)
But not sure what remotecool and remoteheat are?
Does that match other car’s capabilities? Or suggestions for more?
Regards, Mark.
On 11 Nov 2019, at 5:15 AM, Jaunius Kapkan <jaunius@gmx.com> wrote:
Hi,
While doing Leaf HVAC/Climate Control Metrics I tought it would make sense to put them under v.e. or a new climate category like v.h or v.cc and agree on general metrics that would be used by all cars. Such as: v.e.fan.speed 6 v.e.remotecool no v.e.remoteheat yes v.e.setpoint 21°C v.e.intake def/fresh/recirc v.e.vent def/def-feet/face/face-feet/feet
Then later it would be much easier to make them visible in an app. Also "maxfanspeed" could be added to the config so that the GUI could take the required amount of bars for each car.
Regards, Jaunius
Sent: Monday, November 04, 2019 at 1:09 PM From: "Jaunius Kapkan" <jaunius@gmx.com> To: "OVMS Developers" <ovmsdev@lists.openvehicles.com> Subject: [Ovmsdev] Nissan LEAF: HVAC Metrics Hi,
I have enhanced Nissan LEAF HVAC metrics as well as added additional ones under xnl.cc
I have built and tested the changes and so far all works as intended.
I have also updated documentation.
So I think it is time to merge this in to current edge build, but I just wanted to check with you if all the code style and naming conventios are according to standards.
Would appreciate if someone could review and advise if something needs to be corrected.
Here is the link to the repo and main file I worked on: https://github.com/mjkapkan/Open-Vehicle-Monitoring-System-3/commits/master/...
Kindly,
Jaunius Kapkan [Sent from cellphone]
Global Market Operations
Cell: +370 650 11 752
On 2019-10-17, at 15:14, Jaunius Kapkan <jaunius@gmx.com> wrote:
Thanks Mark,
[renaming subject]
In regards to config store. Where would you recommend placing the timers? I was thinking about putting them under vehicle conf: OVMS# config list vehicle vehicle (readable writeable) bms.alerts.enabled: yes bms.dev.temp.alert: bms.dev.temp.warn: bms.dev.voltage.alert: bms.dev.voltage.warn: cctimer.evening: 1715-1730 cctimer.morning: 0800-0815 id: ****** minsoc: 20 name: timezone: EET-2EEST,M3.5.0/3,M10.5.0/4 timezone_region: Europe/Helsinki units.distance: K Any other suggestions?
Regards, Jaunius
Sent: Monday, October 14, 2019 at 4:01 AM From: "Mark Webb-Johnson" <mark@webb-johnson.net> To: "OVMS Developers" <ovmsdev@lists.openvehicles.com> Subject: Re: [Ovmsdev] WifiConsole V1.0 Probably not. The majority of power consumption is from the modems (cellular and wifi).
Regards, Mark
P.S. If all you need is a 10 second notification, you can pubsub subscribe to the standard event ticker.10.
On 14 Oct 2019, at 7:22 AM, Jaunius Kapkan <jaunius@gmx.com> wrote:
Delayed events seem to be working fine, thanks for the examples! However, do you think spamming the events API every 10 seconds might substantially increase power consumption?
[2:17:04 AM]usr.CCtimer.heartbeat [2:17:04 AM]usr.CCtimer.Night.stopped [2:17:14 AM]usr.CCtimer.heartbeat Regards, Jaunius Sent: Sunday, October 13, 2019 at 8:54 PM From: "Michael Balzer" <dexter@expeedo.de> To: ovmsdev@lists.openvehicles.com Subject: Re: [Ovmsdev] WifiConsole V1.0 Sending notifications is now also supported directly:
https://docs.openvehicles.com/en/latest/userguide/scripting.html#ovmsnotify
Regards, Michael
Am 13.10.19 um 16:09 schrieb Jaunius Kapkan:
Great,
Will try that out!
Regards, Jaunius
Sent: Sunday, October 13, 2019 at 11:20 AM From: "Michael Balzer" <dexter@expeedo.de> To: ovmsdev@lists.openvehicles.com Subject: Re: [Ovmsdev] WifiConsole V1.0
Jaunius,
I've added scheduled (delayed) events & the native OvmsEvents API: https://docs.openvehicles.com/en/latest/userguide/scripting.html#internal-ob...
So you can now also implement millisecond resolution timeouts and intervals in scripts.
Regards, Michael
Am 11.10.19 um 10:36 schrieb Jaunius Kapkan: > Thanks Michael, > > 1 second will do just fine as this is for climate control timer plugin I'm doing. Will try to use that event listener. Of course some standartized way would > be better. > > Regards, > Jaunius > > *Sent:* Friday, October 11, 2019 at 8:48 AM > *From:* "Michael Balzer" <dexter@expeedo.de> > *To:* ovmsdev@lists.openvehicles.com > *Subject:* Re: [Ovmsdev] WifiConsole V1.0 > Jaunius, > > setTimeout() is not a standard Javascript function, it's a method of the browser window object. > > https://developer.mozilla.org/de/docs/Web/API/WindowTimers/setTimeout > > As a workaround, subscribe to the "ticker.1" event as shown in the foglight example: > > http://docs.openvehicles.com/en/latest/components/ovms_script/docs/foglight.... > > Resolution is limited to 1 second though. I thought about scheduled events some time ago, i.e. being able to tell the event system to trigger an event after a > specific delay. That would also offer a clean & simple solution for this. Another option would be a script API for the timer service. > > I'll have a look at scheduled events. > > Regards, > Michael > > > Am 11.10.19 um 08:29 schrieb Jaunius Kapkan: > > Thanks Mark, > > One other thing I stumbled upon is that standard setTimeout() does not seem to work. Is there any workaround for this? Sample Code: > > |function intervalFunc() { print('Next try in 1.5s') } setInterval(intervalFunc, 1500)| > > > Basically I need the script to check certain conditions each n seconds. > > Regards, > Jaunius > *Sent:* Thursday, October 10, 2019 at 3:35 AM > *From:* "Mark Webb-Johnson" <mark@webb-johnson.net> > *To:* "OVMS Developers" <ovmsdev@lists.openvehicles.com> > *Subject:* Re: [Ovmsdev] WifiConsole V1.0 > I think in v2 that could have been the case (as we didn’t have any standardised functions for things like climate control). But in the v3 architecture we > now have these and the vehicle modules should support the standard functions to the best of their abilities. > > If we still need mappings like Homelink 1 -> Climate On, then that should be done either by scripts or by some centralised mapping framework. > > Regards, Mark. > > > On 9 Oct 2019, at 2:19 PM, Jaunius Kapkan <jaunius@gmx.com> wrote: > > > > I am making a couple of plugins (initially for leaf) and the JS functions are great for that. However I assume the functions are not unifed accross > different vehicles. For example for leaf to turn on pre-heat you need to issue Homelink 1 instead of ClimateControl. What would be the best way to change > this? Or is this something that need to be changed on the lower level? > > > > Greetings, > > Jaunius > > > >> Sent: Tuesday, October 08, 2019 at 9:05 AM > >> From: "Michael Balzer" <dexter@expeedo.de> > >> To: ovmsdev@lists.openvehicles.com > >> Subject: Re: [Ovmsdev] WifiConsole V1.0 > >> > >> Mark, > >> > >> yes, the OLEDs are perfect for these things, bright enough for daylight use with very little energy usage. > >> > >> Thanks for the link to that combined ESP32 module, that's a real beauty, even includes a LiPo supply / charger. I need to check that one out. > >> > >> Regarding our Javascript support, I already had stunned some users with the foglight plugin, they thought stuff like this would need builtin > >> support. That brought me back to my point about how little users know about our capabilities, so I added an explanation to our docs: > >> > >> http://docs.openvehicles.com/en/latest/components/ovms_script/docs/foglight.... > >> > >> But we really need something like an OVMS cheat sheet as an overview of what is possible. > >> > >> Regards, > >> Michael > >> > >> > >> Am 08.10.19 um 05:40 schrieb Mark Webb-Johnson: > >>> Michael, > >>> > >>> I really like those little OLED SSD1306 based displays. I use them on my esphome+hassio projects like this little water tank level (using an > >>> ESP32, a BME280 pressure/humidity/temperature sensor, waterproof ultrasonic distance sensor, and SSID1306 OLED yellow/blue display): > >>> > >>> > >>> Adding a display to a project makes it so much more useful and easy to diagnose problems. > >>> > >>> AliExpress has them very cheap: > >>> > >>> * https://www.aliexpress.com/item/32844104782.html > >>> US$2 for the 0.96” yellow/blue 128x32 > >>> US$3 for the 1.3” white 128x64 > >>> > >>> > >>> There is also a 4MB ESP32 with a 0.96” OLED display on-board: > >>> > >>> * https://www.aliexpress.com/item/32822105291.html > >>> US$9 plus shipping > >>> > >>> > >>> Glad that you are finding a use for our JavaScript support. I really think that has so many possibilities. > >>> > >>> Regards, Mark > >>> > >>>> On 6 Oct 2019, at 10:43 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: > >>>> > >>>> FYI: I've just implemented an OVMS v3 style replacement for the SimpleConsole: > >>>> > >>>> https://github.com/dexterbg/WifiConsole > >>>> > >>>> V3 makes it pretty easy now to add stuff like this. It's using a script plugin to provide custom functions via the web API. > >>>> > >>>> Regards, > >>>> Michael > >> > >> -- > >> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > >> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 > >> > >> _______________________________________________ > >> OvmsDev mailing list > >> OvmsDev@lists.openvehicles.com > >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev > >> > > _______________________________________________ > > OvmsDev mailing list > > OvmsDev@lists.openvehicles.com > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev > > > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev > > > -- > Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal > Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 > _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev