Thanks @sihui I will add that into the documentation and test it. I will also add a BatterylevelLimit item and use this in a BatterylevelLimit Rule using the charge mode trick.
I have been testing the PRE-heat HVAC. The HVAC=ON command goes to the MyRenaultServer then I query the new state. I do this too quickly because the server waits for the car to confirm the HVAC state. The binding polls 10 min later and gets the ON state. This is confusing and frustrating for users. I need to change this to set state then wait query loop with timeout for the hvacUpdateStatus to be after the command and set the status from that… This means the ON command takes some time but not 10 mins. I also have to block repeated ON commands… I guess…
The behaviour of sitemaps did not change from openHAB2 to openHAB3. They do work just great and for me are the best choice if using openHAB 90% via smartphone.
Quick guide:
install BasicUI through MainUI.
copy the contents of my sitemap in a file called renault.sitemap (mandatory) in your sitemaps folder.
Call the sitemap via http://<ip>:<port>/basicui/app?sitemap=renault
You could also call the sitemap directly from MainUI in the top right corner:
If coding around this is getting too complicated I would not even bother to read the ON state: if the car has received the hvac command the timestamp is updated. That is a clear indication that the car is preconditioning (this of course is the view of a non programmer )
In this case the hvac switch would be just a command switch, not a status switch.
Not that I am aware of. The format depends on the regional settings of openHAB and maybe even on the locale of your operating system.
I thought you would be interested in the English version of timestamps as those are different from my German version (12h/24h and mm-dd-yyyy instead dd.mm.yyyy).
If you want it in a different format I can try to change that, otherwise you will find the different format options here: https://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html
I won’t be availabe today as I have a working day …
To fix the timestamp display I have added a state pattern to the item.
“%1$tH:%1$tM %1$td.%1$tm.%1$tY” For example this outputs: “15:47 21.01.2022” which is hopefully a good international default. This can be overridden in the Item metadata.
I am testing the binding and it looks good so far. I added a trigger to the limit rule and have fixed the update display. Other than that there are no changes. It will be tested next week by the wife so it has to work! I will start the pull request because this will probably also produces some changes…
Any testing and problems / feedback you have time for would be great. Also if the documentation covers is OK. It is always hard to explain stuff that you understand to people that have not spent hours on the problems… so any improvements to the README.md would be great.
2022-01-24 12:51:08.047 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'RenaultZOEHvacstatus' received command ON
2022-01-24 12:51:08.050 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RenaultZOEHvacstatus' predicted to become ON
2022-01-24 12:51:08.073 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RenaultZOEHvacstatus' changed from NULL to ON
2022-01-24 12:51:08.080 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RenaultZOEHvacstatus' changed from ON to PENDING
2022-01-24 12:51:39.722 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RenaultZOEHvacstatus' changed from PENDING to ON
charge limit cutoff works
2022-01-24 09:41:51.504 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'RenaultZOEChargingmode' received command schedule_mode
2022-01-24 09:41:51.510 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RenaultZOEChargingmode' predicted to become schedule_mode
2022-01-24 09:41:51.515 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RenaultZOEChargingmode' changed from always_charging to schedule_mode
2022-01-24 09:44:13.046 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'RenaultZOEChargingmode' received command always_charging
2022-01-24 09:44:13.054 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'RenaultZOEChargingmode' predicted to become always_charging
2022-01-24 09:44:13.060 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'RenaultZOEChargingmode' changed from schedule_mode to always_charging
(first part via rule, then switched manually back to always_charging)
@sihui Unfortunately the version I have is buggy… The Pull request feedback has improved the code but means I have broken the latest version. I have to fix it again and improve the code standard and then it should get merged into the main branch for the SNAPSHOT openhab. Not sure when I will have time for this but hopefully the next couple of weeks.
When this happens you will have to delete the test versions and re set up your Car “thing”.
hey Doug while using the binding I discovered a little bug.
the channel odometer sends a km value to a number:length item.
The number length item would expect a meter value.
The state of the item does look correct in the first place, but in my case the analysis screen for the item odometer shows a value of 2238910 km instead of 2238,91 km:
Great. I would like to have an openHAB 3 UI component for the README as an example. We have a sitemap code thanks to @sihui which will be hopefully added with the open pull request. An openHAB 3 UI page would be great to do in addition as I suspect more an more users will be migrating to UI 3.
You can send me your code (post it here and tag me) when you are happy with it or submit it directly to openhab as a README pull request change.
)
