I’m trying to get a new house up and running and am forgetting some of the initial configuration steps needed to get all the links working properly.
I attempted to use the Insteon terminal on a pi, but after a week of troubleshooting I just went back to the houselinc standby. Houslinc got up and running quick and all of the links between devices are done… but when OH starts up, I get
device 43.B8.59 not found in the modem database. Did you forget to link?
For pretty much all of the devices. Makes me think I missed a step.
I added and can control all of the devices from houselinc, but do I also need to set the PLM as a controller and responder to each device?
Did you use the same modem when you were linking your devices with houselinc? If yes, houselinc should have entered all the devices into the modem’s link database. Also, the openhab binding dumps the contents of the modem database on startup. Does that one look good?
I am using the same modem … there’s only 4 reported devices are startup from the binding, but houselinc has ~40 that i’ve setup links on.
20:53:55.978 [INFO ] [g.insteonplm.InsteonPLMActiveBinding] - modem database has 4 entries!
20:53:55.979 [DEBUG] [g.insteonplm.InsteonPLMActiveBinding] - item KEYPAD_Vestibule2_C binding changed: addr=43.9C.85|prodKey:F00.00.16|feature:keypadbuttonC|params:group=17
20:53:55.980 [DEBUG] [g.insteonplm.InsteonPLMActiveBinding] - modem db entry: 46.54.6E
20:53:55.982 [DEBUG] [g.insteonplm.InsteonPLMActiveBinding] - modem db entry: 44.85.CE
20:53:55.985 [DEBUG] [g.insteonplm.InsteonPLMActiveBinding] - modem db entry: 46.2E.D4
20:53:55.987 [DEBUG] [g.insteonplm.InsteonPLMActiveBinding] - modem db entry: 46.54.D6
That is very strange indeed. You should see all of them. HouseLinc definitely updates the modem database, I don’t think they can do it any other way.
You don’t have by any chance a Hub as well, and openhab is connecting to that hub rather than the PLM?
Remarks:
- The debug log output looks pretty dry. I think Rob Nielsen @ranielsen put additional info in there long ago. Are you running some ancient version of the binding? Try swapping it out with the latest version, maybe the additional details are helpful.
- Did you not get insteon terminal to work at all? If you can just connect to the modem and do “modem.getdb()”, that should give you a clean dump of what you are linked to.
this is a fresh install from apt-get. Karaf reports version 1.1.0, but that
doesn’t seem accurate. Should i use a different version?
189 | Active | 80 | 1.10.0 | openHAB Insteon PLM Binding
I’ll read through the logs and try some more scenarios to see if any other
inspiration comes up. There’s no hub on this network, just the plm and a
bunch of switches and dimmers.
re: insteon terminal… i very much wanted this to work, but couldn’t ever
get it to connect properly. I read through the user groups and found a few
others were having java issues when trying to connect, which is where I
think I left it. So I just switched back to using houselinc.
i’m sure this is related – but I can control everything from OH, but i’m
not getting status back. Should I set the PLM as both a controller and
responder to each device from houselinc?
You should link both ways always.
However, even if you link just one-ways, there should be an entry in your modem database. Your log doesn’t show any. Are you even using the PLM modem, or does your openhab.cfg file still point to a hub?
just the plm… i’ll make that houselinc modification and see what happens
made some progress today Bernd… would love some feedback.
Went through and tested everything and I am getting status updates back
from all of my keypads. What’s explicitly missing is my in-line relay and
dimmers though.
For this setup, all of my lights are controlled by in-line insteon
relays/dimmers and controlled by a keypad without any load.
When a keypad sends a group message out to the in-line devices to turn
on/off, OH gets the keypad button status update, but not the in-line
device’s status update. I believe this is expected behavior based on the
insteon protocol, but it puts a real hamper on my system’s design here…
I’ve been meaning to experiment with the “related” feature in the OH
Insteon binding… but my problem with it is it works well when two switches
are programed exactly alike… but what should I do in the scenario when a
controlled device has multiple keypads with different scenes that control
it? (those scenes containing a mix of other devices they control as well).
– For example, I have a keypad button in my office lobby that turns off
all conference room lights
– In each conference room, i have a keypad to independently control the
two or three lights in the room
I’ll do some experimenting later this week — but i’d appreciate some
feedback on my setup above as I assume it’s fairly common given how
flexible the insteon network can be.
Although your message implies you understand that, just to make it clear: the responders (in this case the in-line relays) will not emit any messages when triggered by a group broadcast from your keypads.
But what speaks against openhab listening to the keypads in the first place? You know that when the keypads are toggled, the in-line relays will follow, so implicitly you also know their state changed. You may as well program your openhab logic to respond to the keypad device’s messaging, rather than the state of the device they ultimately manipulate.
Let’s say you nevertheless absolutely want to hook your openhab logic into the end device. Then you can use the “related” keyword. Remember that you can list multiple devices after the related keyword, separated by ‘+’, see wiki. So let’s say keypad A triggers 5 devices, then you’d hook an item up to keypad A, and put all of the 5 devices behind the “related” keyword. When then binding gets the update for keypad A, it will poll the status of all “related” devices, so even though they don’t actively send an update, the binding will learn about it. Of course, if the PLM modem doesn’t get the update from Keypad A, you are screwed, and will have to wait for the periodic poll to update the state of your inline relays.
Worked perfectly Bernd – I knew this feature would be powerful, I just
never got to testing it… much appreciate your hard work.
