Insteon broke on upgrade to 4.3

tommycw10 · December 22, 2024, 4:18pm

Hi all,

I see that with the introduction of OH 4.3 it brought a new Insteon binding. I’m quite happy about this as it seem that it will add a good deal of functionality missing or only available through insteon-terminal or other 3rd party config apps.

Anyway, this upgrade has broken a couple of my items and I’m trying to figure out the best way to get my system back up and running without essentially removing all of my (legacy) devices and re-adding everything under the new system. I do plan to do this eventually to get this new functionality but this is gonna take some time.

The main things that are now broken are the scenes and three keypads that I had manually defined in a .things text file.

Thing insteon:device:875c5d81af:40D16E "Insteon - Group Broadcasts" (insteon:network:875c5d81af) [address="40.D1.6E", productKey="0x000045"] {
	Channels:
		Type switch : broadcastOnOff#7  "Alloff"
		Type switch : broadcastOnOff#10 "KitrecKitDGrp"
		Type switch : broadcastOnOff#11 "LivingroomKitBGrp"
		Type switch : broadcastOnOff#14 "porchFanLightGrp"
		Type switch : broadcastOnOff#19 "TVModeScene"
		Type switch : broadcastOnOff#21 "ComputerRoomAM"
		Type switch : broadcastOnOff#22 "UpBathAM"
		Type switch : broadcastOnOff#23 "MasterAM"
		Type switch : broadcastOnOff#26 "LeavingScene"
		Type switch : broadcastOnOff#27 "ArrivalScene"
		Type switch : broadcastOnOff#28 "UpstairsOff"
		Type switch : broadcastOnOff#29 "goodnightscene"
}

Thing insteon:device:875c5d81af:28A422 "Insteon - Master Bedroom Keypad" (insteon:network:875c5d81af) [address="28.A4.22", productKey="F00.00.15"] {
	Channels:
		Type switch : keypadButtonA "Button A" [ group="0xF3" ]
		Type switch : keypadButtonB "Button B" [ group="0xF4" ]
		Type switch : keypadButtonC "Button C" [ group="0xF5" ]
		Type switch : keypadButtonD "Button D" [ group="0xF6" ]
}

Thing insteon:device:875c5d81af:2BAD52 "Insteon - Kitchen Hall Keypad" (insteon:network:875c5d81af) [address="2B.AD.52", productKey="F00.00.15"] {
	Channels:
		Type switch : keypadButtonA "Button A" [ group="0xE3" ]
		Type switch : keypadButtonB "Button B" [ group="0xE4" ]
		Type switch : keypadButtonC "Button C" [ group="0xE5" ]
		Type switch : keypadButtonD "Button D" [ group="0xE6" ]
}

Thing insteon:device:875c5d81af:2B9FFD "Insteon - Porch Fan Light Keypad" (insteon:network:875c5d81af) [address="2B.9F.FD", productKey="F00.00.15"] {
	Channels:
		Type switch : keypadButtonA "Button A" [ group="0xD3" ]
		Type switch : keypadButtonB "Button B" [ group="0xD4" ]
		Type switch : keypadButtonC "Button C" [ group="0xD5" ]
		Type switch : keypadButtonD "Button D" [ group="0xD6" ]
}

I tried removing these keypads from the .things file and I added one through the MainUI GUI, however I cannot figure out how to define the group numbers on this device in this GUI. I’ve read over the documentation, and I’ve noted that there is a part that says:

While previously, keypad buttons required a broadcast group to be configured, the binding now automatically determines that setting, based on the device link databases, deprecating the group channel parameter.

I suspect this only applies to the new device types and not “legacy” device types.

Does anyone know how to add group info here? Maybe some JSON in the device configuration area?

Similarly - with my scenes not working, I see you can now add scenes through the main UI, but this appears to only be available if you create a new insteon:plm (or hub) device. I’m happy to do that once I move my whole system to this, but since I assume I can only have either insteon:network or insteon:plm connected to my plm and not both at the same time, I’m not sure how to handle scenes here.

jeshab · December 23, 2024, 6:50am

Could you provide detailed on what exactly is broken? The new binding included in OH 4.3 is backward compatible with the legacy version. So it should work with the configuration you had in OH 4.2 and below.

I just run a test on my end with a similar thing text file and the legacy workflow is working as expected.

This is correct.

Correct again. You can’t use any of the new enhancements with the legacy things. You will need to migrate your environment to the new things to do so. In the meantime, you should be able to use your scenes as you use to via the modem device thing or setting the group parameter on the keypad button channels.

tommycw10 · December 23, 2024, 2:33pm

Hi @jeshab

Thanks for the quick reply.

On further Investigation I’ve come to the conclusion that my keypads are not broken as I had suspected, which seems to confirm what you said about creating similar text file to mine and it worked in your system.

I has thought that they were broken as pressing any of the scene buttons did not trigger rules they are supposed to trigger. I have a few devices that I use to trigger rules.

Keypad scene buttons
Dimmers
Dimmer “Fast” or Double press

What I now realize is that it seems that OH is not seeing ANY physical button presses from my devices. Whether this is coming from a Keypad scene button, the Keypad’s dimmer, a single or double dimmer (2477D) press.

I walked around the house pressing all physical devices on my 2nd floor. Most did not show up in my OH log at all. I had two devices partially show up:

Pressing my C scene button on my Master Bedroom keypad showed this once, but trying again immediately and nothing shows up now. All of the rest of the buttons show nothing in the log:

2024-12-23 08:49:19.066 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'masterC' changed from OFF to ON
2024-12-23 08:49:25.059 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'masterC' changed from ON to OFF

Pressing On/Off on my stairs dimmer (which is physically linked to stairsSlave dimmer at the bottom of the stairs, and also has its onlevel set to 50%) gave this again once, but then not again on subsequent tries:

2024-12-23 08:51:08.471 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'stairs' changed from 0 to 100
2024-12-23 08:51:08.473 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'stairsSlave' received command 100
2024-12-23 08:51:08.475 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'stairsSlave' predicted to become 100
2024-12-23 08:51:08.476 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'stairsSlave' changed from 0 to 100
2024-12-23 08:51:09.779 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'stairs' changed from 100 to 50
2024-12-23 08:51:09.781 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'stairsSlave' received command 50
2024-12-23 08:51:09.783 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'stairsSlave' predicted to become 50
2024-12-23 08:51:09.784 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'stairsSlave' changed from 100 to 50

So it seems that I have some kind of issue where OH is not seeing physical devices being changed, and therefore not triggering rules associated with them.

Using once device as an example, I used insteon terminal and confirmed that they device is properly cross linked to the modem, so this is not a problem.

To further confirm, using a different 2477D dimmer I confirmed I see nothing in my log when I press the button physically. Next, I disabled my insteon network item, created a new insteon plm item and created a new item for one 2477D dimmer. I was also now able to see able to see this device changing state in the log:

2024-12-22 23:48:12.845 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'livingroom' changed from 100 to 0
2024-12-22 23:48:12.848 [INFO ] [openhab.event.ChannelTriggeredEvent ] - insteon:device:71b4fc0fe7:5641ab:event-button triggered PRESSED_OFF
2024-12-22 23:48:17.509 [INFO ] [openhab.event.ChannelTriggeredEvent ] - insteon:device:71b4fc0fe7:5641ab:event-button triggered PRESSED_ON
2024-12-22 23:48:17.513 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'livingroom' changed from 0 to 100
2024-12-22 23:48:20.760 [INFO ] [openhab.event.ChannelTriggeredEvent ] - insteon:device:71b4fc0fe7:5641ab:event-button triggered DOUBLE_PRESSED_OFF
2024-12-22 23:48:20.761 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'livingroom' changed from 100 to 0
2024-12-22 23:48:22.760 [INFO ] [openhab.event.ChannelTriggeredEvent ] - insteon:device:71b4fc0fe7:5641ab:event-button triggered DOUBLE_PRESSED_ON
2024-12-22 23:48:22.761 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'livingroom' changed from 0 to 100

ranielsen · December 23, 2024, 6:39pm

@tommycw10. I’m using the 4.2.3 version of the Insteon binding with 4.3. I shared it at org.openhab.binding.insteon-4.2.3.jar - Google Drive.

jeshab · December 23, 2024, 6:45pm

So I found the problem. It wasn’t apparent due to how you have configured your channels in your thing text files, which is incorrect from the legacy standpoint. I am not even sure that these channels were functioning as expected prior to OH 4.3. The channel type should have been in line with the original channel id. For example, your channel id broadcastOnOff#7 should have been configured with chanel type broadcastOnOff and not switch. Likwise, channel id keypadButtonA should use channel type keypadButtonA.

With the new binding, the legacy channel type have been renamed with a legacy prefix. So broadcastOnOff is now legacyBroadcastOnOff and keypadButtonA is now legacyKeypadButtonA. This rename is automatically done by the binding during the migration process if the related device things were configured in MainUI. However, it is not when configured via a thing text file. This means there is a breaking change in that specific case that I didn’t think of originally.

Now going back to your configuration. Because you used the switch channel type, these channels are using the new switch channel type which has no parameter configured. While your broadcastOnOff channels should still be initialized, your keypadButton* channels wouldn’t because the group parameter is not recognized. If you had the proper configuration, it would be the same issue because the old channel type no longer exists.

To resolve this, update the channel types in your thing text file adding the legacy prefix and restart your Insteon bridge to force the affected device things to go through their initialization process:

Thing insteon:device:875c5d81af:40D16E "Insteon - Group Broadcasts" (insteon:network:875c5d81af) [address="40.D1.6E", productKey="0x000045"] {
	Channels:
		Type legacyBroadcastOnOff: broadcastOnOff#7  "Alloff"
		Type legacyBroadcastOnOff: broadcastOnOff#10 "KitrecKitDGrp"
		Type legacyBroadcastOnOff: broadcastOnOff#11 "LivingroomKitBGrp"
		Type legacyBroadcastOnOff: broadcastOnOff#14 "porchFanLightGrp"
		Type legacyBroadcastOnOff: broadcastOnOff#19 "TVModeScene"
		Type legacyBroadcastOnOff: broadcastOnOff#21 "ComputerRoomAM"
		Type legacyBroadcastOnOff: broadcastOnOff#22 "UpBathAM"
		Type legacyBroadcastOnOff: broadcastOnOff#23 "MasterAM"
		Type legacyBroadcastOnOff: broadcastOnOff#26 "LeavingScene"
		Type legacyBroadcastOnOff: broadcastOnOff#27 "ArrivalScene"
		Type legacyBroadcastOnOff: broadcastOnOff#28 "UpstairsOff"
		Type legacyBroadcastOnOff: broadcastOnOff#29 "goodnightscene"
}

Thing insteon:device:875c5d81af:28A422 "Insteon - Master Bedroom Keypad" (insteon:network:875c5d81af) [address="28.A4.22", productKey="F00.00.15"] {
	Channels:
		Type legacyKeypadButtonA : keypadButtonA "Button A" [ group="0xF3" ]
		Type legacyKeypadButtonB : keypadButtonB "Button B" [ group="0xF4" ]
		Type legacyKeypadButtonC : keypadButtonC "Button C" [ group="0xF5" ]
		Type legacyKeypadButtonD : keypadButtonD "Button D" [ group="0xF6" ]
}

Thing insteon:device:875c5d81af:2BAD52 "Insteon - Kitchen Hall Keypad" (insteon:network:875c5d81af) [address="2B.AD.52", productKey="F00.00.15"] {
	Channels:
		Type legacyKeypadButtonA : keypadButtonA "Button A" [ group="0xE3" ]
		Type legacyKeypadButtonB : keypadButtonB "Button B" [ group="0xE4" ]
		Type legacyKeypadButtonC : keypadButtonC "Button C" [ group="0xE5" ]
		Type legacyKeypadButtonD : keypadButtonD "Button D" [ group="0xE6" ]
}

Thing insteon:device:875c5d81af:2B9FFD "Insteon - Porch Fan Light Keypad" (insteon:network:875c5d81af) [address="2B.9F.FD", productKey="F00.00.15"] {
	Channels:
		Type legacyKeypadButtonA : keypadButtonA "Button A" [ group="0xD3" ]
		Type legacyKeypadButtonB : keypadButtonB "Button B" [ group="0xD4" ]
		Type legacyKeypadButtonC : keypadButtonC "Button C" [ group="0xD5" ]
		Type legacyKeypadButtonD : keypadButtonD "Button D" [ group="0xD6" ]
}

As far as a permanant fix, it seems that the framework is preventing a given thing from going through its initialization process in this case. So I don’t see how it can be resolved without users having to update their text configuration. To be clear, this only affects legacy device things with custom channels textual configuration. I will make sure to add a section in the documentation mentioning the break change for this specific use case.

jeshab · December 23, 2024, 7:19pm

Thanks for your detailed response. I think there are two issues that need to be separated here.

The first one about your keypad scene button not being referenced. This is related to my previous reply above where your keypad device things that had custom channels configuration weren’t being initialized by the new binding and therefore would explain your observation. Once you make the necessary changes I listed below, it should work again.

The second one about the known issue with the recurrence of button press event registration with the legacy implementation. I experienced it in the past and there have been posts in this forum about it. To be clear no change has been made to that workflow. This was the main reason why triggered events support was introduced with the new workflow to differentiate button press events from the actual state of the device.

tommycw10 · December 23, 2024, 8:11pm

Hi @jeshab

Thank you for your help on this.

Sticking just to the scenes for now: I’ve used the .items file you provided. With this, I don’t see any channels listed in mainUI, and all of my previously linked items to these scenes are now listed as broken:

These are the links I previously had:

Switch	Alloff																										{channel="insteon:device:875c5d81af:40D16E:broadcastOnOff#7"}								//{insteonplm="40.D1.6E:0x000045#broadcastonoff,group=07"}						//Group 07 (decimal) is 07 (hex)
Switch	KitrecKitDGrp														(Lights, g1F_Lights)					{channel="insteon:device:875c5d81af:40D16E:broadcastOnOff#10"}								//{insteonplm="40.D1.6E:0x000045#broadcastonoff,group=10"}						//Group 10 (decimal) is 0A (hex)
Switch	LivingroomKitBGrp													(Lights, g1F_Lights)					{channel="insteon:device:875c5d81af:40D16E:broadcastOnOff#11"}								//{insteonplm="40.D1.6E:0x000045#broadcastonoff,group=11"}						//Group 11 (decimal) is 0B (hex)
Switch	porchFanLightGrp													(g1F_Porch, Lights, g1F_Lights)			{channel="insteon:device:875c5d81af:40D16E:broadcastOnOff#14"}								//{insteonplm="40.D1.6E:0x000045#broadcastonoff,group=14"}						//Group 14 (decimal) is 0E (hex)
Switch	TVModeScene				"TV Mode"																			{channel="insteon:device:875c5d81af:40D16E:broadcastOnOff#19"}								//{insteonplm="40.D1.6E:0x000045#broadcastonoff,group=19"}						//Group 19 (decimal) is 13 (hex)
Switch	ComputerRoomAM																								{channel="insteon:device:875c5d81af:40D16E:broadcastOnOff#21", expire="10m,OFF"}			//{insteonplm="40.D1.6E:0x000045#broadcastonoff,group=21", expire="10m,OFF"}	//Group 21 (decimal) is 15 (hex)
Switch	UpBathAM																									{channel="insteon:device:875c5d81af:40D16E:broadcastOnOff#22", expire="10m,OFF"}			//{insteonplm="40.D1.6E:0x000045#broadcastonoff,group=22", expire="10m,OFF"}	//Group 22 (decimal) is 16 (hex)
Switch	MasterAM																									{channel="insteon:device:875c5d81af:40D16E:broadcastOnOff#23", expire="10m,OFF"}			//{insteonplm="40.D1.6E:0x000045#broadcastonoff,group=23", expire="10m,OFF"}	//Group 23 (decimal) is 17 (hex)
Switch	LeavingScene			"Leaving Scene"																		{channel="insteon:device:875c5d81af:40D16E:broadcastOnOff#26"}								//{insteonplm="40.D1.6E:0x000045#broadcastonoff,group=26"}						//Group 26 (decimal) is 1A (hex)
Switch	ArrivalScene			"Arrival Scene"																		{channel="insteon:device:875c5d81af:40D16E:broadcastOnOff#27"}								//{insteonplm="40.D1.6E:0x000045#broadcastonoff,group=27"}						//Group 27 (decimal) is 1B (hex)
Switch	UpstairsOff				"Upstairs Off"																		{channel="insteon:device:875c5d81af:40D16E:broadcastOnOff#28"}								//{insteonplm="40.D1.6E:0x000045#broadcastonoff,group=28",channel="mqtt:topic:7fcb49cba3:UpstairsAll"}	//Group 28 (decimal) is 1C (hex)		//mqtt="<[opi:orbital/upstairs/all:command:ON:1],<[opi:orbital/upstairs/all:command:OFF:0]"}
Switch	goodnightscene			"Goodnight Scene"																	{channel="insteon:device:875c5d81af:40D16E:broadcastOnOff#29"}								//{insteonplm="40.D1.6E:0x000045#broadcastonoff,group=29"}						//Group 29 (decimal) is 1D (hex)

jeshab · December 23, 2024, 8:15pm

Have you made the configuration update I listed above? Make sure to restart your Insteon bridge or OH server to force the affected device things to go through their initialization process.

tommycw10 · December 23, 2024, 8:56pm

Hi @jeshab

Not sure what happened there but I had tried re-saving the .things files and now my channels are there and my links to items are no longer broken.

Anyway, trying to trigger any of my scenes doesn’t seem to work, in that none of the scene participants are changing state to my scene request.

One scene here is scene 28, which is supposed to turn off all devices in the upstairs of my house. This includes my computer room light (3D.F7.A1).

Noting that 28 decimal is 1C hex, you can see below that from Insteon-terminal my computerroom dimmer is linked to respond to group 1C (28) by going to level 0 at RR 29.

>>> computerRoom.getdb()
getting db, be patient!
sent db query msg, incoming records:  1 2 3 4 5 6 7 8 9 10dbbuilder.done() is called
0fff modem                          40.D1.6E  RESP  10101010 group: 01 ON LVL:   0 RMPRT:  28 BUTTON:   1
0ff7 modem                          40.D1.6E  CTRL  11100010 group: 01 ON LVL:   3 RMPRT:  28 BUTTON:   1
0fef modem                          40.D1.6E  RESP  10100010 group: 07 ON LVL:   0 RMPRT:   0 BUTTON:   7
0fe7 modem                          40.D1.6E  RESP  10100010 group: 15 ON LVL: 255 RMPRT:   1 BUTTON:   1
0fdf modem                          40.D1.6E  RESP  10100010 group: 1a ON LVL:   0 RMPRT:   0 BUTTON:  26
0fd7 modem                          40.D1.6E  RESP  10100010 group: 1c ON LVL:   0 RMPRT:  29 BUTTON:   1

So I expect that when I trigger group 28 (1C) from openhab that this dimmer should respond by turning off, but it does not.

I put the binding’s log into DEBUG mode and tailed it for about 2 mins after trying to trigger this scene 28 (1c). I put it here:

I’m still not sure what is going on here.

jeshab · December 24, 2024, 7:56am

So the legacy binding doesn’t seem to handle textual configuration updates on things with already linked channels. I just did a test on OH 4.2 and I get the same result. Basically, each time you update the configuration, the updated things are removed and re-added but the associated channels that were linked previously are not relink at the binding level. This means that when you send a command to that channel, the binding doesn’t recognize the channel and therefore no action is taken.

You need to make sure to either restart your network bridge or OH server each time you update your thing configuration file.

Also for your group broadcasts thing, you should use the deviceConfig parameter instead of specifying each channels. This is the only way currently to migrate these channels. Otherwise, your migrated thing will have no configured channels. I may look to have a hotfix for this one.

Thing insteon:device:875c5d81af:40D16E "Insteon - Group Broadcasts" (insteon:network:875c5d81af) [address="40.D1.6E", productKey="0x000045", deviceConfig="{'broadcastGroups': [7,10,11,14,19,21,22,23,26,27,28,29]}"]

tommycw10 · December 24, 2024, 7:37pm

Thanks @jeshab

I changed my .things file to define the group broadcasts as you noted and now my group broadcasts are working again. TBH, I never knew the proper format for this JSON. I see it shown in the docs but it gives an example for a single group broadcast, so I was unsure how to do this for multiple:

Not sure if there a way to name these in this format, but it probably doesn’t matter since this is temporary while I am migrating to the new style devices.

jeshab · December 24, 2024, 7:45pm

Unfortunately, you can’t customize the channel labels using that method.

tommycw10 · December 24, 2024, 8:15pm

@jeshab

Thanks again for all of your help on this. It is greatly appreciated.

I had originally reported two issues:

Scenes not working. That part has been solved! (Thank you again!)
Keypads not working, which turned out to actually being that none of the physical device button presses are seen by OH, so no rules I have set up to trigger on button presses fire. This problem persists. I had originally thought it was just keypads but I also trigger a couple rules on either single to double (aka “fast”) presses on 2477D dimmers.

My computer room 2477D is supposed to trigger a rule to turn off two other lights in the room (non-insteon so I can’t physcially link them together)

This dimmer’s insteon address is: 3D.F7.A1, and its item is defined below and linked to a legacy thing, which is connected to the legacy insteon network bridge.

Dimmer	computerRoom				"Computer Room Lights [%d %%]" /*name set in sitemap*/				(Lights, g2F_Lights, gLightkWh)		["Lighting"]	{channel="insteon:device:875c5d81af:3DF7A1:dimmer"

and it is supposed to trigger this small rule:

rule "Monitor light off with room light"
	when 
		Item computerRoom changed to 0
	then
		logInfo("Computer Room Dimmer", "!!!!!!!!!!!!!!!!!!!!!! Turning off monitor back light & lava lamp")
		sendCommand(computerRoomMonitor,OFF)
		sendCommand(orbitalIO,OFF)
	end

This rule never gets triggered. Looking at the log, there is nothing that gets written to the log to indicate that the device was pressed or the log message from the rule.

So I went into the console and put the log into debug mode. I then pressed the computer room dimmer to turn it off and captured a few seconds of the log after the button press here:

Please let me know if there is something els eI can do to debug this.

jeshab · December 24, 2024, 8:22pm

Can you confirm that this didn’t behave that way in OH 4.2 and earlier? I am looking to resolve backward compatibility issues (which should be mostly configuration issues opposed to functional ones) and not existing issues with the legacy binding.

tommycw10 · December 24, 2024, 8:25pm

Completely understood. Yes, confirmed this worked in prior releases. These rules have been running for many years without issues. Not sure about this particular rule, but I’ve been running OH since version 1.