I am pretty much just starting to learn OpenHAB right now and for the most part things are going pretty well but I’m stuck on a small issue. I’m using the InsteonPLM binding and just doing some initial testing with a simple switch that controls the front porch light. I set up the binding, set up the item, and set up the sitemap and all of that works fine. I’m able to control the light from the sitemap, turning it on and off and it responds right away.
The only problem I have is when I turn the light on or off with the Insteon App it doesn’t update on the OpenHAB sitemap. I am following the openhab log in debug mode and I get the message “Cannot retrieve item null for widget org.openhab.model.sitemap.Frame”. I’m also following the insteonPLM log and I notice that when I change the state of the switch on the app the binding receives the notification, it just doesn’t update the sitemap. Is there a setting I’m missing?
This indicates there is an error on your sitemap .
First of all, why are you created these Frames? With just a few Items why not simplify matters a lot and eliminate the Frames and then gradually add them back in once you get things working. Especially since the error is complaining about the Frame.
One other thing that stands out to me is Date is a reserved word. I’m not sure this is a problem for the sitemap but it will be a problem in Rules. Try renaming it so something like CurrentDate.
I’m using the Frames to organize everything on my sitemap. If I don’t use Frames things show up in odd places. Regardless I removed the Frames and just used the Switch and it still didn’t resolve the issue. I also changed the name of the Date variable to CurrentDT to avoid any keyword conflicts and no success.
When I remove the Frames I no longer get that debug message in the log but it still does not update properly
Also I am using Frames according to the documentation and according to the demo sitemap so I don’t see where the issue should be there. But either way, I removed them and the problem is still there.
I’m not telling you not to use frames ever. Just when you see an error that is complaining about the frames, and the frames are essentially non-funcitonal, try removing them to try and identify the real problem.
In short, if it doesn’t work, simplify until you are as basic and have a few variables to deal with as possible.
If the error went away then the problem didn’t go away. It is just now manifesting in a different way. Any new errors in the log?
Have you tried to refresh the sitemap after it has received an update from the physical switch? On OH 1 there is a known issue where sometimes the sitemap doesn’t refresh automatically like it should. I’ve only ever seen it on the Android app but I think there have been reports of it happening on the web sitemap as well. Its fixed in OH 2, won’t be fixed in OH 1.
Yeah, I understand what you mean. Sorry hopefully that didn’t come across as cross, I just meant I wasn’t sure what was happening since I followed the documentation. But yeah simplification didn’t seem to help unfortunately. Those are the only errors I see in the log. I have it at DEBUG level, I could take it to trace level yet to see if anything else is happening. I did enable logging on the insteonPLM binding and when I activate the switch with the Insteon App I get the following:
2016-08-30 19:13:07 [DEBUG] o.o.b.i.internal.driver.Port[:382] - writing (500): OUT:Cmd:0x62|toAddress:2F.47.8A|messageFlags:0x0F=DIRECT:3:3|command1:0x19|command2:0x00|
2016-08-30 19:13:08 [DEBUG] o.o.b.i.i.d.RequestQueueManager[:132] - device queue for 2F.47.8A is empty!
2016-08-30 19:13:08 [DEBUG] o.o.b.i.InsteonPLMActiveBinding[:581] - got msg: IN:Cmd:0x50|fromAddress:2F.47.8A|toAddress:3C.D4.82|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x08|command2:0x00|
2016-08-30 19:13:08 [DEBUG] o.o.b.i.i.d.MessageDispatcher[:134] - 2F.47.8A:GenericDimmer DIRECT_ACK: q:QUERY_PENDING cmd: 80
2016-08-30 19:13:08 [DEBUG] o.o.b.i.i.d.MessageDispatcher[:139] - changing key to 0x19 for msg IN:Cmd:0x50|fromAddress:2F.47.8A|toAddress:3C.D4.82|messageFlags:0x2F=ACK_OF_DIRECT:3:3|command1:0x08|command2:0x00|
2016-08-30 19:13:08 [INFO ] o.o.b.i.i.d.MessageHandler[:533] - DimmerRequestReplyHandler: set device 2F.47.8A to level 0
2016-08-30 19:13:08 [DEBUG] o.o.b.i.i.device.DeviceFeature[:264] - 2F.47.8A:GenericDimmer publishing: 0
2016-08-30 19:13:08 [DEBUG] o.o.b.i.i.d.MessageDispatcher[:159] - defdisp: 2F.47.8A:GenericDimmer set status to: QUERY_ANSWERED
2016-08-30 19:13:08 [DEBUG] o.o.b.i.i.device.DeviceFeature[:264] - 2F.47.8A:GenericLastTime publishing: 2016-08-30T19:13:08
I will also note that if I leave it sit long enough it will eventually update everything but it takes a couple minutes to do that. I’m also doing this using the App and not the physical switch. My test setup is a little unorthodox. But I will test it with the physical switch tonight and see if I get better results. If I do it might be an App issue.
So I worked on this a little further and found some interesting things about working with the Insteon App.
I do a decent amount of traveling for work and wanted to be able to work on my system away from home so I set up VPN access to my home network so I could network in to the RPi when I was away. That part works great, but I’m obviously not home to physically monitor the devices. So I use the Insteon for Android App. I can toggle things with OpenHAB and then refresh the Insteon App to see the results. That part works great.
The trouble is, when you toggle an Insteon device from the Insteon for Android App the device changes but no actual update is sent to the OpenHAB binding. Network activity is generated regarding the hub but no device update is sent. So after getting home I opened the OpenHAB sitemap, went to the physical device in my house, turned it on and immediately the device on the sitemap updated as it should.
So if you’re using the Insteon for Android App be aware that when you change states of a device using the App it will not update the InsteonPLM binding for that device. I tested this at home and sure enough it doesn’t work even when everything is directly on the same network.
Hope this helps someone, I’ll post it as resolved. If anyone has any other thoughts on that though I’d be interested to hear if anyone else ran into any issues like this.
This would be really good information to add to the wiki page, if you don’t mind. Unexpected limitations like these are really important to get in the documents.
