Insteon PLM - Adding New Device Features

Hi, I am using the Insteon PLM binding with Insteon Hub 2242-222 and thermostat adapter 2441V. I have setup the database on the Hub (Which i believe is based on the 2441TH), and everything is communicating. However it seems that the data is packaged differently in data1, data1b and data2. (This may be the difference between the actual thermostat and thermostat adapter) So commands to the thermostat work but the rest of the data is mismatched, for example humiditylow actually contains the current temperature value.

Do I need to remap this data on the modem database first?
I created a new device, and a new feature. But I get the error that the item references an unknown feature.

Any help would be appreciated.

Thanks in advance
Michael

@Bernd_Pfrommer any ideas? I see that the 2441V is listed as supported with the Insteon terminal (https://github.com/pfrommerd/insteon-terminal), but not with the binding.

“Supported” is a bit of a strong statement, because that’s all the code you will find for the 2441V in InsteonTerminal :slight_smile:
#-------------------------------------------------------------------------------

Insteon Thermostat 2441V

from thermostat import Thermostat

class Thermostat2441V(Thermostat):
"""============== Insteon Thermostat 2441V ==============="""
def init(self, name, addr):
Thermostat.init(self, name, addr, 0x0fff)

First of all, thank you for your replies.

I was able to find the developer’s notes for the 2441V. It looks to me like data1 data1b and data2 is already being read by the binding (this is the data I believe is mismatched)

So theoretically I could remap the data. But it’s not clear to me if this is something that would have to be done on both the modem side and the binding side?

Extended Command
Message Direction
From Address (3 bytes)
To Address (3 bytes)
Message type
Cmd1 (1 byte)
Cmd2 (1 byte)
Data 1 (1 byte)
Data 2 (1 byte)
Read Data To device Sender’s ID
Device’s ID
Extended Direct
0x2E 0x00 0x00 -> 0xFF (Group/Button)
See Read Data Info
Response Device’s ID Sender’s ID
Standard Ack
0x2E 0x00 Same as sent N/A

Read Data Info Data 2 Description 0x00 Data 2: 0 is for Read Data (Responder unit will send back a Data 2: 1 below)

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 Notes All temp data is not x2; LED 00=Off, 01=On (Red or Green), 02=(Red); Fan 00=Auto, 10=On

Read Data Info
Data 3 Data 4 (1 byte)
Data 5 Data 6 Data 7 Data 8 Data 9 … Data 14
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

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.

Is is possible to make a custom feature for an existing device?
I created a custom feature xml file (enabled it from openhabb.cfg) and pasted your code for ThermostatHumidityLow

I enabled extended logging, and there is a log entry

2016-12-26 23:02:04 DEBUG o.o.b.i.InsteonPLMActiveBinding[:220]- item thermostatHumidityLow binding changed: addr=14.B9.48|prodKey:F00.00.18|feature:humiditylow

But it doesn’t seem to be doing anything. The data is still showing from Actual Temperature. (so… Data5)

Do I need to make a custom device to inherit the custom features? or should this replace the existing “ThermosatHumidityLow” and apply to any existing devices in device_types.xml ?

Read “Adding new device features” section here:

In your items file, just pretend it is a 2441TH, i.e. device type F00.00.18.
Then copy the original device_features.xml to my_device_features.xml and reference it in openhab.cfg:

insteonplm:more_features=/wherever_the_file_lives//my_own_features.xml

On startup, the binding will first load the original file, then your “my_own_features.xml” file. All definitions in “my_own_features.xml” will overwrite the original feature definitions.

make sure you see a message in the log that it is actually reading your my_own_features.xml file

For good measure you can put a corrupted entry in there and make sure it croaks.

Switch on debug logging (as described in the wiki), then you should see traffic from the thermostat.

And of course, you have to restart openhab when you change openhab.cfg

Here is what I did:

  1. created “more_features.xml”

  2. Inside more_features.xml I pasted the following code

<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>
  1. Point openHAB to this file -> insteonplm:more_features=C:\repos\openhab\features\more_features.xml

  2. Start openHAB, check insteonplm.log see the following entry:

2016-12-27 11:17:08 INFO o.o.b.i.InsteonPLMActiveBinding[:309]- reading additional feature templates from C:\repos\openhab\features\more_features.xml

This indicates to me that the binding is parsing the more_features.xml file.

My item definition is as follows:

Number thermostatHumidityLow “humidity low [%d %%]” { insteonplm=“14.B9.48:F00.00.18#humiditylow” }

And based on the messaged returned from the insteon device I expect my item = 0x1D (29% humidity) but the item = 0x48 (72 degree actual temperature)

got msg: IN:Cmd:0x51|fromAddress:14.B9.48|toAddress:31.46.7B|messageFlags:0x11=DIRECT:1:0|command1:0x2E|command2:0x00|userData1:0x01|userData2:0x01|userData3:0x01|userData4:0x1D|userData5:0x48|userData6:0x4B|userData7:0x49|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xB2|

So it seems that the custom device feature is not doing anything. Because the value I am seeing is still userdata5 which is the default for ThermostatHumidityLow

Can you please let me know if I am missing something here?

Thanks

So I tried with garbage entry. Same status - log does not show any errors related to low_byte="Jimmy"
But log shows

reading additional feature templates from C:\repos\openhab\features\more_features.xml

And the item is still updating with the live value from the thermostat (Actual Temperature)

<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="Jimmy">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>

Can you screw up the XML syntax, like unbalanced tags. The parser should throw an error then.

I found the issue. I did not enclose the feature in

 <xml> </xml>

I will continue to modify the features per the dev notes for this module and report back my findings. My intention is to get the full set hacked so others may use this module.
Thank you for your help thus far.

I sense competence :slight_smile:

Don’t want to be greedy, but ideally, you’d also modify the device_types.xml file, add a new device there for the 2441V (pick the next free number in the Fxxxxxx number space), then rather than modifying, add new features to the device_features.xml, and refer to those in your new device. That way we can directly incorporate your new device in the official repository.

2441V_device.xml (824 Bytes)
2441V_features.xml (7.5 KB)

This is what I have so far (See attached files). All of these features are working. I had a problem when I tried to rename the features.

in 2441V_features.xml

<feature name="something_new">

In 2441V_device.xml

<feature name="coolsetpoint">something_new</feature>

Not sure what I missed there?

The only issue I have found is ThermostatSystemMode, this module reports the correct system mode. So I used the NumberMsgHandler instead of the ThermostatSystemModeReplyHandler. However this thermosat will report 2 additional modes. 5=Program heat 6=Program cool. They look to be redundant, and the ThermostatSystemModeReplyHandler catches this by using an else condition to assume any other mode means mode = 4. I can handle this in my application, but I am not sure if there is a clean way to handle this without the need for a new Reply handler.

On my todo list is evaluate if it’s possible to read these additional modes which are in the dev notes.

Status Reporting Mode/Fan Status  From device Device’s ID 
 Direct 0x70 0x00 = Off  0x01 = Heat  0x02 = Cool  0x03= Auto 0x04 = Program 0x05 =Program Heat 0x06 = 
 Program Cool  
… 0x10 = Off-Fan On 0x11 = Heat-Fan On 0x12 = Cool-Fan On 0x13 = Auto-Fan On 0x14= ProgramFan On 
0x15 = Program Heat-Fan On 0x16 = Program Cool-Fan On 0x17=> Not Used

Because then I would be able to determine if the fan is running for the humidifier.

The ThermostatSystemMode only collects 0x00 - 0x06. I am not sure how to read the next 4 bits?

Thanks again for all your help. Despite taking 5 years off the life of my furnace and running the A/C with 6’’ of snow on it I am glad to have this device working correctly. And I hope others can use it.

Michael,
Looks like you are making good progress!
Not sure what you mean with “I had a problem”… but what you tried to do should’ve worked. I can’t easily test so I just hacked your venstar stuff into the full device/feature list. Can you please test if the files below work?

device_types.xml (18.5 KB)
device_features.xml (48.6 KB)

insteonplm.xml (35.5 KB)

Not sure what’s going on. In theory, I should not have to change anything in my openhab application aside from pointing to your revised xml files in my openhab.cfg

as I am already using F00.00.21 in my insteon.items.

Number	thermostatCoolPoint	"Cool Setpoint [%.1f °C]"	(Thermostat)		{ insteonplm="14.B9.48:F00.00.21#coolsetpoint" }

I have attached my insteonplm log file. This is the same result I saw when I tried this. No data showing on the sitemap. It looks to me like it is finding the features for the 2441TH and publishing data to the wrong locations. I let it run for a while and the sitemap does update if the thermostat sends a message when a particular even occurs Example: Heat Turned ON (but no data from the data1b_group is showing at all) . So it’s the same behavior as when I was initially trying to use the 2441TH prior to modifications.

Does Feature name have to also be a unique identifier in device_types.xml?

<feature name="alsosomethingdifferent?">VenstarCoolSetPoint</feature>

Traveling… Earliest response on the weekend.