Not really sure how or where to ask this question but I have several devices hooked up through an Insteon hub which I can get to work with OpenHAB2. This means that I know there is communication going on but whenever I startup an OpenHAB UI most, if not all depending on the situation, of the devices are not showing the correct status. Meaning that some switches show being on which are in fact off. The thermostat seems to update pretty consistently and that appears to be the only thing.
Now as soon as I start interacting with any of the devices through the UI that particular device starts reading the status correctly, or maybe I should say displaying the status correctly which I may assume means it has updated it’s last action in some sort of database. Any idea how I can get everything to do a check on the status of each controller when the app is first started?
Is your hub linked to these devices as both responder and controller?
Which hub are you using?
Which insteon binding are you using? (there is an “Insteon Hub” binding that is old and not really used, and an “Insteon PLM” binding that actually supports hubs too (better than the old hub binding).
I believe the Insteon Hub is the 2245-222, post 2014, and I am running OpenHAB2 using the new Insteonplm binding. The Insteon Hub is acting as both the controller and responder. The app for Insteon does show the correct status of all devices so the information between the Insteon Hub and the devices is correct.
I assume then it is just when I start the OpenHAB2 UI that it is not starting out by communicating with the Insteon Hub to receive some sort of status report.
Just to make sure - when you say “start the openhab UI” I’m assuming you are running the openHAB server continuously correct?
So the way that using the post 2014 hub works, is that when you locally change a device at the switch (lets use a 2477D dimmer as an example), the dimmer sends info to the hub staying that it has changed from off to on for example. The hub then knows immediately - this is why your insteon app knows the state. Openhab every so often (configurable in your .cfg file) asks the hub what the status of everything is. The hub then responds and openhab updates the item’s status. Once this happens, this info should be immediately available to any UI attached, and to any UI started after that happens as well. A newly started UI should not need to go and find out each item’s status. It is already known by the server.
When the server first starts up, it doesn’t know the status of any device, so it has to go out and actively poll for status on every item. This takes time to accomplish.
When you actually change an item in openHAB( again say a 2477D dimmer from off to on) first the binding sends the on command and them immediately polls to find the status (in case you have a max value on your dimmer and the on command doesn’t take it to 100%). It would them have the new correct status immediately.
Can you post your openhab.cfg, your .item & .sitemap line or lines for an example item?
If using openHAB, I highly suggest not using the insteon app for any control over your system. It is OK to use to configure devices and occasional things like that, but openhab won’t know of the things you do in the app until it polls the hub again. That can take minutes.
Thanks for the insight. I will post the information tomorrow as I am at work currently and not able to do so now. I typically don’t use the Insteon app except for testing or adjusting a setting on a device. I must have missed the .cfg aspect of this scenario, which may be part of the issue. I am still in the testing stages of setting up OpenHAB2 but do typically leave it running constantly on a Pi3 until I am updating it.
I think the .cfg works a little different in OH2. I’ve been running 1.8 for a while and haven’t wanted to upgrade yet. The .cfg is where you tell openhab how to connect to your hub and some other bits. A the very least you should have a line like this:
On a side note, if you are still testing things out before moving to a full insteon system, I’d highly suggest spending the $80 or so on a real PLM. The hub works, but the PLM is much better for OH to deal with. You add a lot of latency using a hub. I started the same way, then bought a PLM but keep the hub around for config and testing purposes.
Thanks for the advice. I do remember adding that bit of information to a file in my initial setup. Do you mind sharing what you’re using in place of the Insteon Hub for daily use?
Not sure of the best way to do this so if I should have added this a different way feel free to correct me. This is the information in the ,items and .sitemap files. Still need to workout using mapping with the Insteon motion sensor and contact door sensors. Logically makes sense but couldn’t accomplish what I wanted as of yet.
Switch CeilingFan "Ceiling Fan" {insteonplm="2F.E2.2F:F00.00.02#switch"}
Switch CabLights "Cabinet Lights" {channel="wemo:socket:CabLights:state"}
Switch FishLights "Fish Lights" {channel="wemo:socket:Socket-1_0-221623K010161D:state"}
Switch RopeLights "Rope Lights" {insteonplm="27.62.18:F00.00.1B#switch"}
Switch BackPorch "Back Porch" {insteonplm="2F.EB.2C:F00.00.02#switch"}
Switch FrontPorch "Front Porch" {insteonplm="2F.E2.A3:F00.00.02#switch"}
Dimmer BasementLights "Basement Lights" {insteonplm="2B.C8.A9:F00.00.01#dimmer"}
Dimmer KitchenLights "Kitchen Lights" {insteonplm="30.07.38:F00.00.01#dimmer"}
Dimmer EagleLamp "Eagle Lamp" {insteonplm="2E.6C.B8:F00.00.19#dimmer"}
Dimmer BedroomLamp "Bedroom Lamp" {insteonplm="2E.50.41:F00.00.19#dimmer"}
// Contact motionSensor "motion sensor [MAP(motion.map):%s]" {insteonplm="2D.A6.17:0x00004A#contact"}
// Number motionSensorBatteryLevel "motion sensor battery level [%.1f]" {insteonplm="2D.A6.17:0x00004A#data,field=battery_level"}
// Number motionSensorLightLevel "motion sensor light level [%.1f]" {insteonplm="2D.A6.17:0x00004A#data,field=light_level"}2D
Contact ScreenDoor "Screen Door [%s]" {insteonplm="2D,BF.69:0x00049#contact"} //Still not getting any information from sensor but InsteonHUB is working perfect.
Number doorSensorBatteryLevel "Door sensor battery level [%.1f]" {insteonplm="2D.BF.69:0x00049#data,field=battery_level"}
Number thermostatCoolPoint "Cool point [%.1f °F]" { insteonplm="2F.80.C3:F00.00.18#coolsetpoint" }
Number thermostatHeatPoint "Heat point [%.1f °F]" { insteonplm="2F.80.C3:F00.00.18#heatsetpoint" }
Number thermostatSystemMode "system mode [%d]" { insteonplm="2F.80.C3:F00.00.18#systemmode" }
Number thermostatFanMode "fan mode [%d]" { insteonplm="2F.80.C3:F00.00.18#fanmode" }
Number thermostatIsHeating "is heating [%d]" { insteonplm="2F.80.C3:F00.00.18#isheating"}
Number thermostatIsCooling "is cooling [%d]" { insteonplm="2F.80.C3:F00.00.18#iscooling"}
Number thermostatTempFahren "Temperature [%.1f °F]" { insteonplm="2F.80.C3:F00.00.18#tempfahrenheit" }
Number thermostatTempCelsius "Temperature [%.1f °C]" { insteonplm="2F.80.C3:F00.00.18#tempcelsius" }
Number thermostatHumidity "Humidity [%.0f %%]" { insteonplm="2F.80.C3:F00.00.18#humidity" }
Number thermostatACDelay "A/C delay [%d min]" { insteonplm="2F.80.C3:F00.00.18#acdelay" }
Number thermostatBacklight "Backlight [%d sec]" { insteonplm="2F.80.C3:F00.00.18#backlightduration" }
Number thermostatStage1 "A/C stage 1 time [%d min]" { insteonplm="2F.80.C3:F00.00.18#stage1duration" }
Number thermostatHumidityHigh "Humidity high [%d %%]" { insteonplm="2F.80.C3:F00.00.18#humidityhigh" }
Number thermostatHumidityLow "Humidity low [%d %%]" { insteonplm="2F.80.C3:F00.00.18#humiditylow" }
Contact BackDoorClosedSensor "Back door sensor is [MAP(contact.map):%s]" <door> { gpio="pin:27 force:yes"}
Switch BackDoorSwitch "Back Door Lock" <switch> {gpio="pin:05 force:true activelow:yes"}
//GPIO testing
//Switch Pin05 "GPIO05" {gpio="pin:05 force:yes"}
//Switch Pin06 "GPIO06" {gpio="pin:06 force:yes"}
Switch Pin13 "GPIO13" {gpio="pin:13 force:yes"}
Switch Pin19 "GPIO19" {gpio="pin:19 force:yes"}
Switch Pin26 "GPIO26" {gpio="pin:26 force:yes"}
Switch Pin16 "GPIO16" {gpio="pin:16 force:yes"}
Switch Pin20 "GPIO20" {gpio="pin:20 force:yes"}
Switch Pin21 "GPIO21" {gpio="pin:21 force:yes"}
The config file mentioned does have only that line of instructions: port_0=/hub2/my_user_name:my_password@myinsteonhub.mydomain:25105,poll_time=1000 with the appropriate information edited.
These are most of the Insteon devices that I am using. I plan on adding more (non-Insteon) as I build them when I get time. I just have too many Insteon though to not incorporate them if I can get the actual status to display correctly. Especially the hard wired switches. I also want to make sure I clearly understand you on one thing. It sounded like to me you are running the OpenHAB program on whatever hardware then you have a separate PLM that you are using to communicate directly to your device, Including the Insteon ones, and you have the Insteon hub running as well but only using it if needed to update device settings. Do you turn the Insteon hub off when not in use to eliminate conflicts? It was also funny to me the you mentioned the lag. That was one of the first things I noticed in the Insteon devices respond much quicker to the OpenHAB app on my phone the Insteon does with it’s own app on my phone.
Also, you don’t need the “label=” part here. You already have that defined in the item and redefining it here will make it not show the mapping you have in the item.
Other than these two item, I don’t see anything standing out. Unless that item with the comma instead of the period is making the binding fail, I don’t see why it wouldn’t be polling and knowing the status of everything. Try fixing that stuff and see if that helps. After that, we probably need to start looking at the log files.
For use in openhab I use the Insteon Power Line Modem (PLM) like this one:
They also make a USB version, but they are really the same thing. So I have my PLM configured in my .cfg to work with openHAB, but I do not connect my hub to openHAB anymore. I just comment out that line. I don’t unplug it (although I guess I could), I just don’t connect it to openHAB.
As for lag, I’m not sure why the insteon app would respond slower than the openHAB app for commanding items. I’d have thought they’d be similar. openHAB does command quickly using either the hub or PLM. I think the lag comes in - in knowing the status of items that change on their own. Like getting the command from a motion sensor or something like that. My motion sensor was almost useless using the hub. The reaction was just too slow.
Thank you so much for your time and patience. It’s the details that will kill you and yes the comma was the solution. I can’t begin to count how many times I looked that script over and never noticed. Just got a new split ergonomic keyboard and I am not use to the spacing yet. I will definitely look into just using the PLM over the HUB. Are you still using the HUB to create scenes or just defining rules in OpenHAB, which is what I was going to start transitioning to since I have the desire to have non-Insteon devices interact with Insteon.
The lag thing is an oddity but I am not sure of the whole process the HUB goes through to interpolate the data stream between it and any Insteon apps being used. Possibly OpenHAB is just better directly communicating in some way.
None the less again thank you so much for spotting my errors and helping me to correct them.
Do you use the editor (I think it is called eclipse smart home designer) in OH2? It checks syntax and highlights errors in real time. Like you said, it is always the small things that get you. I could never write clean code without that help.
I used to use the hub to define scenes and such, but here is the issue. Lets use this example:
Scene - two lights on 50%:
Hub = controller - sends out group message on group (for an example group number) 0x0A
DimmerA = responds to group 0x0A lighting to 50%
DimmerB = responds to group 0x0A lighting to 50%
You kind of have no way to trigger this scene without using the app, and doing so from the app is not what you want to do.
Insteon-terminal is written by the same guy who wrote the openHAB Insteon binding. It is a VERY powerful tool, however it has a pretty good learning curve.
What I suggest is that for all insteon to insteon connections you link the hardware to control things when ever possible. Like if you have a 3 way switch - cross link the two switches to control and respond to one another independent of openHAB, then openHAB can just update itself based on their signals. If you are doing scenes mixed with insteon items and non-insteon items are turning on/off many insteon items, I’d suggest creating a scene in insteon, triggering that scene with openHAB and then commanding the non-insteon items on/off. That way the insteon stuff will all happen in parallel and the non-insteon stuff will follow in series. Much faster that way.
I’ve found that the insteon hardware is pretty powerful. It is really nice hardware, however it takes some time to understand how to best leverage it with openHAB.
Actually I don’t use an editor. Since I have OpenHAB running on a Pi3 I just use Leafpad, a simple GUI text editor that comes with Raspbian, and that’s it. Heard the name eclipse in various places but had no idea it had anything to do with coding. I will look into that. Really only been trying out the OpenHAB2 for a few days now, guess going on two weeks, and I am impressed with it overall so far. Just a bit of a learning curve and it takes me a little longer now days for some things to click. l look forward to looking at the Insteon terminal as well. I did go ahead and order the PLM you had mentioned. Someone had them for $40 shipping included on clearance.
Again thanks for all your insight and suggestions like the best way tackling the integration of Insteon with non-Insteon devices. I am sure you have saved me weeks of frustration.
Just an update. Installed the Eclipse SmartHome Designer and love it. Makes life a whole lot easier troubleshooting.
