@hpetersen: What address did you use when using my python script?
@zmartify: I managed to update the binding, and got a lot of error messages about the serial port not working, until I added it to /etc/default/openhab2:
ā¦ and the setpoint on the thermostat changes. Likewise, if the setpoint is changed on the thermostat, the change is reflected in openhab as well. Very nice
I did initially have some problems getting this working. Not really sure why, but after restarting openHAB, it seems to be working now.
Okay, so far so goodā¦
I got the binding working. Or sort of
I deletede all of the manual config files and set it up throu paperUI as you suggested @spiff42. Thank you.
I can now see everything is online, all my room thermosats is listed and in the log i see lots of communication with the Wavin AHC9000.
You can do it by PaperUI, but I prefer a file. /etc/openhab2/items/heating.items:
Number UtilityRoomManualTemp "Bryggers Setpunkt [%.1f Ā°C]" <temperature> { channel="zmartmodbus:jablotrontp150:407cef13:adr1c0e3:ManualTemp" }
Number UtilityRoomAirTemp "Bryggers luft [%.1f Ā°C]" <temperature> (gHeatingAirTemps) { channel="zmartmodbus:jablotrontp150:407cef13:adr1c0e3:AirTemperature" }
Number UtilityRoomFloorTemp "Bryggers FloorTemp [%.1f Ā°C]" <temperature> { channel="zmartmodbus:jablotrontp150:407cef13:adr1c0e3:FloorTemperature" }
Number UtilityRoomComfortTemp "Bryggers Comfort [%.1f Ā°C]" <temperature> { channel="zmartmodbus:jablotrontp150:407cef13:adr1c0e3:ComfortTemp" }
Number UtilityRoomEcoTemp "Bryggers Eco [%.1f Ā°C]" <temperature> { channel="zmartmodbus:jablotrontp150:407cef13:adr1c0e3:EcoTemp" }
Number UtilityRoomHolidayTemp "Bryggers Holiday [%.1f Ā°C]" <temperature> { channel="zmartmodbus:jablotrontp150:407cef13:adr1c0e3:HolidayTemp" }
Number UtilityRoomStandbyTemp "Bryggers Standby [%.1f Ā°C]" <temperature> { channel="zmartmodbus:jablotrontp150:407cef13:adr1c0e3:StandbyTemp" }
Number UtilityRoomPartyTemp "Bryggers Party [%.1f Ā°C]" <temperature> { channel="zmartmodbus:jablotrontp150:407cef13:adr1c0e3:PartyTemp" }
Number UtilityRoomDesiredTemp "Bryggers Desired [%.1f Ā°C]" <temperature> { channel="zmartmodbus:jablotrontp150:407cef13:adr1c0e3:DesiredTemp" }
You can get the information to put into āchannelā from PaperUI. Go to Configuration -> Things and select a thermostat (TP-150). There you see all the channels the thing offers.
For example, I have one listed as āSet Temperature - zmartmodbus:jablotrontp150:407cef13:adr1c0e3:ManualTempā. There is a little icon to the right of the channel. If you click it, the string will be copied to the clipboard, so you can insert it in the .items-file.
Then I have the following in /etc/openhab2/sitemaps/test.sitemap:
On the serial port āthingā called slave1 you can āenable counters" which will tell you if you have a communication problem. Number of time-outs should less than 1%. Possible issues can be cable length, modbus receiver. You may need to terminate your modbus cable depending on the length.
Iām on holiday for the moment, so will only be online occasionally.
I have the new version running now. I still get a bunch of Recv timeout in the log, so maybe I should check bus termination etc. I know for sure that I have enabled 120ohm termination at the USB converter end, but there is probably not any termination at the AHC9000 end (cable is cat5 about 2 meters).
I got it all setup and working now, i can read the tempereatures from system now.
But when i set the desired temperature from within openhab the TP150 does not set the temperature automatically. I have to push the center button on the thermosat and wait about 2-3 seconds before the desired temperature is changed?
Do you experience the same @spiff42?
So far I have only been using ManualTemp for setting and AirTemperature for reading the current temperature. ManualTemp seems to work āboth waysā for me, i.e. changing the ManualTemp item in OpenHAB sitemap seems to change the setpoint on the thermostat (although I can only verify it by pressing the button), and turning the wheel on the thermostat seems to update the ManualTemp item.
I suppose the DesiredTemp should simply reflect one of the other temperatures (ManualTemp, ComfortTemp, EcoTemp, HolidayTemp, StandbyTemp or PartyTemp), based on which mode is selected.
With an old version of the binding I tried to set the mode, but at that time I was unsuccessful (I would like to use party mode and holiday mode, because they shows cute little icons of a cocktail and suitcase on the thermostat).
Maybe the problem you are experiencing is simply that the binding does not find out that desiredTemp changed? As far as I can see, the readings are only updated when the status flags indicate they have changed. This means if I change my sitemap or items definitions, the values are not shown until they change (i.e. AirTemp changes or ManualTemp is changed), or until I restart OpenHAB (which seems to trigger a complete refresh).
But I am not really sure what to use desiredTemp for, at least as long as I have not gotten modes to work.
Those options are taken directly from the Wavin modbus documentation. As I said, with an OLD version of the binding, I had no success getting this to work (with the newest one I have not tested it yet).
From my reverse-engineering of the Wavin display to controller communication, my understanding is as follows (there are no guarantees, but this is how I believe it works):
Depending on the mode, the thermostat will use different registers as the setpoint:
Mode 0 => ManualTemp
Mode 1 => StandbyTemp
Mode 2 => EcoTemp
Mode 3 => ComfortTemp
Mode 4 => PartyTemp
Mode 5 => HolidayTemp
So for instance if ComfortTemp is 22.0 and mode is 3, the thermostat will use 22.0 as the setpoint (and I think this should be reflected in the DesiredTemp register, but I donāt know if the binding updates DesiredTemp item when mode is changed).
For my use with OpenHAB I donāt really need the different setpoints, but as I said, setting party-mode or holiday mode also shows a little icon on the thermostat.
The modes 8 and above are used with a schedule programmed into the AHC9000. I donāt think that makes much sense when OpenHAB is involved - it just complicates things without adding anything.
I suppose using Eco or Comfort could be possible as well, but again I am not sure what that brings. At least in my house where the floor heating is in the bottom of a 10 cm concrete slab, it takes several hours from turning on the heating until the floor is warm, so until now I have not had much luck adjusting the temperatures during the day/night (schedules). This also means that there is not much point in being able to set the thermostats in each room. The display tells me the current temperature, but I usually only need to adjust it if going on holiday, etc.
BTW: I donāt think you are supposed to change DesiredTemp - I think it just reflects the current setpoint (i.e. the same value as ManualTemp, StandbyTemp, etc. depending on which mode is currently active). So if mode is 0 and you want to change the setpoint, you change ManualTemp.
If you meant that you are changing ManualTemp, but the update is not registered, please explain again. As I said, I got the change in ManualTemp working both ways (with only short delay).
Iāve been following this closely, good to see itās getting some attention, one question I have is, can the binding set the clock on the AHC 9000?
I find that I have to do this after power cuts and probably the biggest use I have for the screen now that the schedules are set.
@Sthomas: I think you will run into problems if you are using both this binding and a display (two masters on the bus).
Getting OpenHAB integration, I believe the most logical thing to do is move the schedule to OpenHAB, in which case you do not need to set the time on the controller
Yes I can see that logic but my confidence in the system is not yet where Iād be happy to do that. Plus Iād loose the āplayā aspect if I (read family) rely on it for heating
Happy to remove the screen in time and was curious to see if the main function I use of the screen could be automated by openhab - also like an NTP for the AHC9000
Not sure if the binding can do it, but I have been setting the time in the controller using my python script. However, that was without the display connected.
The display is quite heavy on the bus usage, so getting a time slot to update the time, without the display interfering with communications does not seem easy, but I have no hard evidence it cannot be made to work with sufficient retries. But I donāt know how the display behaves if its communication gets messed up.
Iāve been playing around a bit with the settings. My initial test found āManualTempā to be linked to āDesiredTempā - when I changed āManualTempā it triggered a change of āDesiredTempā and also updated the display on the thermostat. All makes perfect sense.
Then I updaeted EcoTemp to 18 degrees (reported as null initially) and that seemed to mess everything up - āModeā got updated to 12 and it seemed like āManualTempā has been unlinked from the physical thermostat and āDesiredTempā.
I have tried manually changing āModeā to 0 and several other values but no matter what I do it seems that the change is permanent - I have no control from Openhab - but it still gets updates when I operate the thermostat.
Any ideas what might be wrong?
@ThomP: Havenāt had time to look at the timeouts. Could there be differences in the USB-to-serial hardware or driver causing this? @zmartify: Could you tell us which USB-to-serial bridge you have used for development?
My initial test of the binding was using only ManualTemp (as the setpoint), and AirTemperature (for getting the current temperature reading). These were reflected by items in sitemap, and I got ManualTemp working āboth waysā.
However, when I tried to expand the sitemap with an the Mode (pretty much equal to the Selection-item posted by @hpetersen), I got the following behavior: The mode was initially not set to any of the defined values (perhaps null), so it appeared in the selection menu as a new blank item. When I tried to change the mode using the sitemap, it did not seem to set anything on the thermostat.
From my experiments from Python, I know that setting vacation mode shows a little suitcase on the display, but I couldnāt get that working using the binding to set āmodeā.
Maybe I can find a second USB-to-RS485 device and see what is happening on the bus. At this point I find it difficult to determine if it is working or not (or working sometimes). I wonder if there are other ways to debug the binding (@zmartify: would a higher log level reveal something, e.g. seeing when changes are detected, etc.)
