OH 5.0-snapshot #4716 and INSTEON Binding Thermostat Issues

Add-ons Bindings
1

@jeshab
I want to provide you with some feedback for the Insteon Binding ahead of the OH 5.0 release. Over the past two days I have spent some time using the latest Docker OH 5.0-snapshot and evaluating the Insteon Binding. Using an FT232 Serial (UART) to USB cable I connected my PLM to the server running OH 5. The PLM was recognized without issue and I was able to download the database and all of my devices/scenes were recognized and came online. Among the devices I have are dimmers, switches, I/OLinc plugin dimmers and switches, a smoke bridge, garage door openers and sensors, and finally a thermostat. From what I could see during my use, all devices functioned as expected through OH and reported status accordingly, with one exception: the Thermostat (2441TH).

Generally I would say the thermostat was functional up to a point, but there were several very strange behaviors that I think may need some additional attention. First, when switching System Modes from the OFF state to HEAT, the command would be sent properly to the thermostat and the physical thermostat would switch modes. Then after a few seconds for no apparent reason the linked Item would be UPDATED to AUTO, but the physical thermostat would not change modes, remaining in HEAT mode. That is the reason I say it was an UPDATE and NOT a command. Similarly when switching the System Mode from OFF to COOL, the command would be sent to the thermostat, the physical thermostat would switch to COOL as expected, then a few seconds later the Linked Item would UPDATE to HEAT for no apparent reason, but the physical thermostat remained in COOL mode. Further adding to the confusion, if I were to switch modes from COOL to HEAT or HEAT to COOL, or AUTO without using OFF, no random UPDATES to the Linked Item were observed. Setting the Linked Item to OFF did exactly what is expected without any issue. The Linked Item UPDATE only occurred going from the OFF state to some active HVAC MODE. FWIW I have a TRACE log that I have attached, but I didnā€™t see anything obvious. Then again I donā€™t l know exactly what to look for.

The other odd behavior I noted was the temperature reporting. For most of the time I was using the binding, the Temperature reporting/display on OH and the Thermostat were in sync and accurate. However yesterday, suddenly the OH Temperature Item was seeing a temperature of 33Ā°F while the thermostat was showing 76Ā°F. As you might expect all sort of low temperature alarms/rules were triggered but nothing I tried was able to reset the OH display.

Just by way of background, I am running OH 5.0-snapshot #4716 in a fresh docker container. My baseline system federates OH 3 docker with OH 4.x ( now 5.0-snapshot)docker using the excellent Remote OpenHAB Binding. The OH3 Docker is running the ISY Binding 3.0.1 which bridges to a Universal Devices ISY994i/PLM that controls my Insteon devices. This setup is very stable and works well, but is aging and I am concerned that it may soon give out. That is my primary motivation for wanting to switch to the OH Insteon Binding. (N.B. During my evaluation of the Insteon Binding, Remote OpenHAB was disabled and OH3 Docker stopped. I was running/evaluating OH 5.0 solo.) However, without a functional/stable thermostat implementation I am unwilling to commit and have reverted to my baseline setup and all is running fine.

I do believe the Insteon Binding 5.0 is likely very close to perfection, but still needs some tweaking to realize the full potential. This is reason I am doing my best to document my observations, in the hope that you may be able to make the needed adjustments ahead of OH 5.0 GA. Thanks again for your efforts.

Insteon Thermostat Trace.txt (8.7 KB)

2

Thanks very much for taking the time to provide feedback related to the thermostat. Thatā€™s one of the device I didnā€™t get much testing data to determine if the new implementation was working as expected.

The binding updates the thermostat system modes based on two messages:

  • Direct extended message 0x2E in response to status query
  • Out of bound status message 0x70

When sending a command to change modes to the device, the binding will request a status query which will cause both messages to be received by the binding.

Unfortunately, Insteon didnā€™t make it easy as the state mapping for each message is different. I can see that the status query response changed the system mode to HEAT only to be updated to AUTO when the out of bound message is received.

Anyway, I found a bug as the mapping for the out of bound message is incorrectly mapping the received status of 1 to AUTO instead of HEAT. COOL mapping was also incorrect.

2025-07-03 15:03:34.500 [TRACE] [nsteon.internal.device.DeviceFeature] - 50.59.D1:systemMode setting last message value to: 4.0
2025-07-03 15:03:34.501 [DEBUG] [ternal.device.feature.MessageHandler] - ThermostatSystemModeReplyHandler: device 50.59.D1 systemMode is HEAT
[...]
2025-07-03 15:03:36.865 [TRACE] [nsteon.internal.device.DeviceFeature] - 50.59.D1:systemMode setting last message value to: 1.0
2025-07-03 15:03:36.865 [DEBUG] [ternal.device.feature.MessageHandler] - ThermostatSystemModeMsgHandler: device 50.59.D1 systemMode is AUTO

Can you try the latest beta release version? The files attached are compiled for OH 4.3.

Could you run the below console command to log event messages for your thermostat and provide the file output the next time you notice the incorrect data point?

insteon debug startMonitoring 50.59.D1

Feel free to let me know if you find any other issues with that device.

3

@jeshap Yes. I will give it a try and report back. I really want to get this working.

4

@jeshab - Just a quick update. I upgraded to the Insteon Binding using the link that you provided and Iā€™m happy to say that after a few hours of use, toggling the Thermostat System Mode, everything seems to be working as expected. Great job in diagnosing and fixing the issue. I also started a debug log for the thermostat, as you suggested, so we will see any anomalies that may occur. Iā€™ll continue on this path and let you know if I encounter any other problems, but I just wanted to give you some early results. Thanks again for your help and support of OH.

1 Like
5

Thanks. I went ahead and marked the PR as ready to be reviewed/merged. Keep track of it so you will know when the fix will be included in the latest OH5 snapshot version.

Keep me posted. When you experienced the temperature issue, what did you mean by ā€œnothing I tried was able to reset the OH displayā€? Did you try to send REFRESH command to the item linked to the temperature channel? How long did the incorrect temperature was available in OH?

6

So far no temperature issue. I am continuing to log. When the temperature issue occurred I tried a REFRESH and I restarted the Docker but the low temperature display in OH persisted. I do use MAP for persistence so perhaps that was a reason that a restart didnā€™t work. What did work, was deleting the docker container, and updating to the most recent snapshot to create a new docker which I assume trashed the cache and tmp files. I probably should have tried just removing those file manually, before deleting the docker, but I didnā€™t think of that until now.

The other thing I noticed today, and this may not be and Insteon issue, as I was stress testing your updated binding and reconfiguring some Rules (Text Based), when OH was likely parsing the updated text rules, I believe OH would initiate a system restart. I think that is fairly routine, but this restart caused the System Mode Linked Item to UPDATE to AUTO Mode, not the persisted state in the MAP.db. To solve this, I just added a line to system startup rules so that the item.previousState is used for the Linked Item. Otherwise everything seems to be running fine.

1 Like
7

Jeremy, Yesterday and today I have been doing some additional testing using the updated Insteon Binding, first with OH 5.0-snapshot and also with OH 4.3.5. Unfortunately, I have only a small amount of good news, that being I did not experience any issue with the thermostat reported ambient temperature. No low temperature alerts or other anomalies. Both the physical device and OH remained in sync throughout my testing. Now the not so good news. I am still having issues with System Mode changing states after several minutes,(previously it occurred after a few seconds and you seemed to have fixed that), going from HEAT to COOL and COOL to AUTO, then just remaining in AUTO Mode. I noticed this overnight at around 3AM when I check the status and saw that it was no longer in COOL Mode, but in Auto. Then again when woke around 7AM I noted was it in AUTO again even after resetting to COOL at 3AM.

To be certain that it was not something in my rules, today I disabled all rules related to the Thermostat, but after a few minutes the System Mode still changed from COOL to AUTO. To insure that it was not was not an issue with OH 5.0-snapshot being unstable, I installed the updated Insteon binding in OH 4.3.5 hoping for a different result. Unfortunately I observed the same behavior, HEAT changing to COOL and COOL changing to AUTO.

Following this trial, I reverted back to OH 5.0 snapshot, updated to the latest build #4723 started the Debug Log for the Thermostat and a TRACE Log for the Insteon Binding and let them run until the System Mode changed was observed. During this time I changed the Cool Setpoint Temperature so that the AC would run. I also made a rule mod and save, because I have a hunch that any background processing within OH triggers an update to Insteon Things and results in System Mode changes. The bi-directional. communication between the Insteon Binding and the Thermostat just seems very odd, Iā€™m sure not there is much more I can do on my end as a work around, and the current state is not stable enough for my continued use, but I am still hopeful you will be able to resolve this behavior in the binding for the future.

A couple of other minor ā€˜bugsā€™ that I observed are the following:

  1. the Humidity value that is used for the Location Badge is a decimal and not a %. this results in 58% Humidity being seen as .58 and the Badge display 1%. The Humidity Item is Number:Dimenionless [%.0f %%].
  2. The other observation is that the System State does not update to OFF when the System Mode is manually set to OFF. When the HVAC stops running due to meeting the set temperature, all is good, but I think it should go to OFF when the Mode is manually set to OFF as well.

I am willing to evaluate any futures changes you may make to the binding that affect the Thermostat. Just let me know, and again thanks for your efforts.

I originally uploaded the wrong Trace Log. This the correct one with System Mode changing to AUTO
Thermostt Debug Log 7-6-1416.txt (25.2 KB)
Insteon Trace Log 7-6-1416.txt (193.1 KB)

8

The logs you provided donā€™t seem to capture what you are describing. I only see a command to set AUTO at 2025-07-06 14:21:28.750 where the binding is properly setting the system mode to the expected value.

# Insteon status extended direct message received
2025-07-06 14:21:28.722 [DEBUG] [ding.insteon.internal.transport.Port] - got msg: IN:Cmd:0x51|fromAddress:50.59.D1|toAddress:46.C3.16|messageFlags:0x15=DIRECT:1:1|command1:0x2E|command2:0x02|userData1:0x01|userData2:0x05|userData3:0x0B|userData4:0x31|userData5:0x00|userData6:0x30|userData7:0x44|userData8:0x37|userData9:0x00|userData10:0xE0|userData11:0xC0|userData12:0x3F|userData13:0x81|userData14:0x5E|
# SystemMode state updated to AUTO
2025-07-06 14:21:28.735 [DEBUG] [ternal.device.feature.MessageHandler] - ThermostatSystemModeMsgHandler: device 50.59.D1 systemMode is AUTO
2025-07-06 14:21:28.735 [TRACE] [nsteon.internal.device.DeviceFeature] - 50.59.D1:systemMode setting state to: AUTO
# OH command received to set to AUTO
2025-07-06 14:21:28.750 [DEBUG] [nternal.handler.InsteonDeviceHandler] - channel insteon:device:0afde8e759:d4c585e379:system-mode received command AUTO
# Insteon command sent to device
2025-07-06 14:21:29.683 [DEBUG] [ding.insteon.internal.transport.Port] - got msg: IN:Cmd:0x62|toAddress:50.59.D1|messageFlags:0x1F=DIRECT:3:3|command1:0x6B|command2:0x06|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0x8F|ACK/NACK:0x06|
# Insteon command acknowledged
2025-07-06 14:21:30.171 [DEBUG] [ding.insteon.internal.transport.Port] - got msg: IN:Cmd:0x50|fromAddress:50.59.D1|toAddress:46.C3.16|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x6B|command2:0x06|
# SystemMode state updated to AUTO
2025-07-06 14:21:30.175 [DEBUG] [ternal.device.feature.MessageHandler] - ThermostatSystemModeReplyHandler: device 50.59.D1 systemMode is AUTO
2025-07-06 14:21:30.175 [TRACE] [nsteon.internal.device.DeviceFeature] - 50.59.D1:systemMode setting state to: AUTO
# Insteon out of bound system status message received
2025-07-06 14:21:33.656 [DEBUG] [ding.insteon.internal.transport.Port] - got msg: IN:Cmd:0x50|fromAddress:50.59.D1|toAddress:46.C3.16|messageFlags:0x05=DIRECT:1:1|command1:0x70|command2:0x03|
# SystemMode state updated to AUTO
2025-07-06 14:21:33.662 [DEBUG] [ternal.device.feature.MessageHandler] - ThermostatSystemModeMsgHandler: device 50.59.D1 systemMode is AUTO
2025-07-06 14:21:33.662 [TRACE] [nsteon.internal.device.DeviceFeature] - 50.59.D1:systemMode setting state to: AUTO

However, I can see out of bound message updates for different modes with no correspond trace logs. These are driven by local changes on the thermostat.

# COOL
2025-07-06 14:16:33.704 IN:Cmd:0x50|fromAddress:50.59.D1|toAddress:46.C3.16|messageFlags:0x05=DIRECT:1:1|command1:0x70|command2:0x02|
# OFF
2025-07-06 14:16:59.535 IN:Cmd:0x50|fromAddress:50.59.D1|toAddress:46.C3.16|messageFlags:0x05=DIRECT:1:1|command1:0x70|command2:0x00|
# COOL
2025-07-06 14:17:05.289 IN:Cmd:0x50|fromAddress:50.59.D1|toAddress:46.C3.16|messageFlags:0x05=DIRECT:1:1|command1:0x70|command2:0x02|
# AUTO
2025-07-06 14:21:33.710 IN:Cmd:0x50|fromAddress:50.59.D1|toAddress:46.C3.16|messageFlags:0x05=DIRECT:1:1|command1:0x70|command2:0x03|
# COOL
2025-07-06 14:23:21.642 IN:Cmd:0x50|fromAddress:50.59.D1|toAddress:46.C3.16|messageFlags:0x05=DIRECT:1:1|command1:0x70|command2:0x02|

Can you confirm the value on the item state linked to the humidity channel?

Logs are showing the proper value being set:

# Insteon status extended direct message received
2025-07-06 14:21:28.722 [DEBUG] [ding.insteon.internal.transport.Port] - got msg: IN:Cmd:0x51|fromAddress:50.59.D1|toAddress:46.C3.16|messageFlags:0x15=DIRECT:1:1|command1:0x2E|command2:0x02|userData1:0x01|userData2:0x05|userData3:0x0B|userData4:0x31|userData5:0x00|userData6:0x30|userData7:0x44|userData8:0x37|userData9:0x00|userData10:0xE0|userData11:0xC0|userData12:0x3F|userData13:0x81|userData14:0x5E|
# Humidity state updated to 55%
2025-07-06 14:21:28.755 [DEBUG] [ternal.device.feature.MessageHandler] - CustomDimensionlessMsgHandler: device 50.59.D1 humidity is 55 %
2025-07-06 14:21:28.757 [TRACE] [nsteon.internal.device.DeviceFeature] - 50.59.D1:humidity setting state to: 55 %

I have a patch for this one. The system state will be set to OFF when the system mode changes to OFF.

9

I may have edited too much of the log I sent to you, but in the first part of the log Mode should have set to Cool. Using OH that is what I manually set the thermostat mode to. Then after many minutes it resets itself to Auto. I wanted to be sure it was not anything explicitly in my rules that was causing the issue, so I built a clean OH 5 container, with only the Insteon Binding, no rules and only minimal items linked to HVAC Mode. Even in this case I still observed the Mode Setting jump from Cool to Auto. Is Auto the Binding Default? It seems any sort of background processing or reparsing of Items/Rules related to HVAC causes the Mode to reset Auto. Is there anything that could be changed in the binding such that Mode remains at lastChange or similar? I canā€™t say whether it takes 2 minutes or 20 minutes, but it is reproducible. Just to put a fine point on this, the Command to Auto that you reference, was a totally random event, and not something that I set. For now I have reverted to using Remote openHAB and ISY on OH 3 linked to OH5 as that is stable. I know the thermostat is complex and I am willing to help evaluate any changes u may implement. However I will be traveling from July 16 - July 21.

10

Not sure if you saw the update I made to my previous reply, the system mode changes in OH you experienced are coming from the thermostat via out of bound messaging the binding received from the device. Were you or someone in your household interacting with the device? Are you using programs?

The log line below indicates the binding received a command to set to AUTO. This means a command was sent to the item linked to the channel. The binding doesnā€™t trigger these events. Are you sure you donā€™t a rule that might trigger this command?

2025-07-06 14:21:28.750 [DEBUG] [nternal.handler.InsteonDeviceHandler] - channel insteon:device:0afde8e759:d4c585e379:system-mode received command AUTO

If you look at your OH event logs, you should see a relevant event for this command.

11

Actually looking closer to this one, the binding should have set the system state to OFF when the mode changed to OFF. I canā€™t confirm because the trace logs you provided donā€™t cover that time period. Message events show the change should have happened less than a minute after receiving the thermostat mode OFF message.

# Out of bound message indicating the thermostat mode is OFF
2025-07-06 14:16:59.535 IN:Cmd:0x50|fromAddress:50.59.D1|toAddress:46.C3.16|messageFlags:0x05=DIRECT:1:1|command1:0x70|command2:0x00|

# Broadcast message indicating the thermostat state is COOLING OFF (the binding considers this state as OFF)
2025-07-06 14:17:57.893 IN:Cmd:0x50|fromAddress:50.59.D1|toAddress:00.00.01|messageFlags:0xCF=ALL_LINK_BROADCAST:3:3|command1:0x13|command2:0x00|
12

Iā€™m sure that no mode change adjustments were made at the Thermostat or using OH. What I have observed is that if a change to the HVAC rules or items file is made then the Thermostat will revert to Auto in a short time. Likewise if I use OH to adjust the Cool/Heat Setpoint, then in short time the Mode changes to Auto. We almost never touch the physical thermostat. In fact I donā€™t think my wife even knows how to use it.

On further thinking, my recollection is that in most instances, the physical thermostat remains in Cool Mode. Only my mode item is updated to Auto. I will need to double check this, to be sure.

Just a follow-up question. If the Thermostat is generating the event, how can the event be out of bounds? Am misunderstanding something here? Should not the binding trap out bounds events and just ignore them, rather than reverting to Auto?

Are you sure you donā€™t a rule that might trigger this command?

I was concerned that I had errant rule firing, that is why I created a new OH 5 docker container with no rules and only the HVAC items and Insteon binding. Nothing else, and after a time of changing temp it reverted from cool to Auto.

Final thought. If the Physical Thermostat is generating periodic updates, which I have no doubt it does, is possible that something in OH or the Binding is misinterpreting these updates. I believe in the ISY world, the modes are numbers. Is it possible the that modes the thermostat is sending are numbers and are not mapped properly??

  • 0 = OFF:
  • 1 = HEAT:
  • 2 = COOL:
  • 3 = AUTO:
  • 4 = PROG (Program Auto

Just fishing.

I understand your frustration. I am frustrated too. Do u have any other users that have a a thermostat that I might learn from how they are configuring it. I am using the same items and rules that I have used for years with the ISY bridge without issue.

13

Looking closer at the event messages again, I missed the commands that are sent to the device to set the different modes prior to the associated out of bound being triggered. Unfortunately due to the partial trace logs, I canā€™t see how these were generated. I would expect these being triggered the same way as the AUTO command I highlighted above. So my assumption that someone was fiddling with the physical thermostat was incorrect.

Are you sure you arenā€™t mounting your OH configuration volume on the new container? I have done that mistake in the past while testing on a new container.

The binding uses two mappings. The first one is the command mapping used to instruct the device to change its mode. The second one is the status mapping used for out of bound and status reply messages.

public static enum ThermostatSystemMode {
   OFF(0x09, 0x00),
    HEAT(0x04, 0x01),
    COOL(0x05, 0x02),
    AUTO(0x06, 0x03),
    PROGRAM(0x0A, 0x04);
[...]
}

I donā€™t think this is a mapping issue. We need to understand why the binding is sending these commands. Out of curiosity, have you enabled the deviceSyncEnabled parameter on your bridge?

Unfortunately I donā€™t. The thermostat implementation was directly transposed for the most part from the legacy version which I assumed was working. Anyway, we should be able to get at the bottom of this. Could you provide OH event logs, binding trace logs and also the thermostat rules that you are using? Thanks

14

I am 100% certain I did not mount my baseline OH 5 to the new container. I was very careful to insure this did not happen. deviceSyncEnabled is disabled. Iā€™ll try to get some logs over the next day or so. Itā€™s been awfully hot and humid where I live so I really need my AC working properly, but I will do what I can before I travel on the 16th. I will continue to test on my end and look at more rules again. Thanks for sticking with this.

15

Attached is a Trace Log that I ran from a FREASH OH 5.0 Container with only the Insteon Binding loaded from the AddOns Folder, and no rules. Just a few Text Based Items that I linked to the Thermostat Thing Channels(System Mode, Fan Mode, System Status, CoolSetpoint and HeatSetpoint). The Trace starts with Mode Setting set to COOL at approx 18:43:39:193. During the time I was testing the Binding, the only manual changes that I made were to the CoolSetpoint and HeatSetpoint. At approx 18:51:09:809 I adjusted the HeatSetpoint. Immediately after doing so, the Mode Setting switched to AUTO. However the Physical Thermostat remained in Cool Mode. Only the Linked OH item changed to AUTO.

Coincidence? Perhaps, as my observation is that the System Mode Updates/Changes can/do occur with just the passage of time. Like overnight even when we are asleep and no activity to speak of is taking place. Anyway hope this is of value.

Insteon Trace Log 7-12-2025.txt (270.4 KB)