Thanks for pulling me in Rob … somehow I no longer get notice even if the subject is properly tagged … strange.
So what’s the deal with the 2441V vs 2441TH?
If I look at device_features.xml of the insteonplm source tree:
feature name="ThermostatHumidityLow">
<message-dispatcher>DefaultDispatcher</message-dispatcher>
<!-- handles direct extended message after query -->
<message-handler cmd="0x2e" ext="1" match_cmd1="0x2e" match_cmd2="0x00" match_d2="0x01" match_d3="0x01" low_byte="userData5">NumberMsgHandler</message-handler>
<!-- handles direct ack after value has been changed-->
<message-handler cmd="0x19">TriggerPollMsgHandler</message-handler>
<message-handler default="true">NoOpMsgHandler</message-handler>
<command-handler command="DecimalType" ext="1" cmd1="0x2e" d1="0x01" d2="0x0c" value="userData3">NumberCommandHandler</command-handler>
<command-handler default="true">NoOpCommandHandler</command-handler>
<poll-handler>NoPollHandler</poll-handler> <!-- polled by ThermostatData1bGroup -->
</feature>
The comment in the last line tells me that it’s polled by the ThermostatData1bGroup poll handler. What does that one do?
<feature name="ThermostatData1bGroup"> <!-- just does the polling for various quantities -->
<message-dispatcher>PollGroupDispatcher</message-dispatcher>
<poll-handler ext="2" cmd1="0x2e" cmd2="0x00" d3="0x01" >FlexPollHandler</poll-handler>
</feature>
It sends cmd1 = 0x2e, cmd2=0x00, d3=0x01 to the device. The question now is: what does the 2441V do when it gets this message? It sends a reply back, and as it currently stands, it will be treated as follows: if it matches the following pattern it will pull the data out of the “userData5” field:
<message-handler cmd="0x2e" ext="1" match_cmd1="0x2e" match_cmd2="0x00" match_d2="0x01" match_d3="0x01" low_byte="userData5">NumberMsgHandler</message-handler>
Now we have to understand how the 2441V works and what it will reply. You can experiment around with the insteonterminal. That’s what it was written for. Regretfully I have to admit this issue has come up before, and we (Dan and I) dropped the ball:
In the last post you’ll find a link to the developer docs. There on page 8 it says something about the return packet for a 0x2e 0x00 0x00 query. It’s kinda hard to read, but from what I gather, these are the returned values:
0x01 Data2: 1 return of data
Data3: Mode
Data4: Humidity
Data5:Temperature
Data6: Cool Setpoint
Data7: Heat Setpoint
Data8 : LED
Data9 Fan Mode
Data10: N/A
Data11: N/A
Data12: N/A
Data 13: N/A
Data 14: N/A
So looks like Data5 has Temperature, not humidity. This agrees with your observation!
You are in for some hacking if you want to make this work. With a bit of luck it will not involve coding, just config files.
I suggest you read up on the insteonplm wiki section about how to make custom devices and feature handlers. If you drop xml features and devices file into the right folder and reference them from openhab.cfg, they will overwrite the existing device definitions. This will allow you to hack the reply handler to look for userData4 instead of userData5. Also we are currently filtering for data3 == 1, which is not correct, since for the 2441V that contains the “mode” field, which may or may not be equal to 1. Try to edit the message handler in the xml file to look like this:
<feature name="ThermostatHumidityLow">
<message-dispatcher>DefaultDispatcher</message-dispatcher>
<!-- handles direct extended message after query -->
<message-handler cmd="0x2e" ext="1" match_cmd1="0x2e" match_cmd2="0x00" match_d2="0x01" low_byte="userData4">NumberMsgHandler</message-handler>
<!-- handles direct ack after value has been changed-->
<message-handler cmd="0x19">TriggerPollMsgHandler</message-handler>
<message-handler default="true">NoOpMsgHandler</message-handler>
<command-handler command="DecimalType" ext="1" cmd1="0x2e" d1="0x01" d2="0x0c" value="userData3">NumberCommandHandler</command-handler>
<command-handler default="true">NoOpCommandHandler</command-handler>
<poll-handler>NoPollHandler</poll-handler> <!-- polled by ThermostatData1bGroup -->
</feature>
See if that fixes the problem with HumidityLow being incorrect. If it does, then you can go ahead and hack all the other handlers. When you have everything working post the handlers and we’ll fold it into the openhab.
