OMG, that was it. Thanks!
This binding worked fine for me for a while and then all of a sudden I’m being flooded with BRIDGE_OFFLINE messages like
Mar 17 12:10:58 openhab ‘isy: scene:5182d36d:62680’ changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
for all the devices every few seconds. The ISY seems to still work fine along with the devices but the openhab connection is very slow. Has anyone seen this before?
I have developed a homie 3.0 mqtt client for the isy994. Need some help testing and supporting more devices. PM if you know some phython and aren’t afraid of getting your hands dirty.
Hi guys,
I know this is an old thread but I’m still hoping for some help.
I’m trying to set up my OH2 integration with ISY through OH2 ISY binding and I would like to configure it in such way that I only control my scenes and not individual items in ISY. This will help me in the future if I need to swap any devices and I won’t need to touch OH config files for any changes. Also it helps to keep my keypad switches in sync, however I can’t figure out how to configure my scenes in OH (items or things) to be able to control some of them with the dimmer function instead of the switch function. Did any of you have figured this out? I would really appreciate some help.
Thank you in advance
Scenes can only be switches - Insteon scenes are preset and you cannot set a scene to a level. Either turn it on or off…
Thank you Michael for you reply. Let me ask you then a different question, If I set my dimmer to any level directly from OH my other keypads won’t update to reflect the current “ON” status of this scene even if they are linked to the same scene so my question is there any other way to accomplish this by not controlling the scene?
Agree, this is a very frustrating problem - keeping keypad buttons matching the current scene.
I keep keypad buttons in sync by running programs on the ISY. Its a PIA to setup but works. Let me know if you are interested.
Hi Michael,
If you don’t mind sharing your program rule from ISY and how you keep these buttons in sync with the dimmer that would be great.
Vlad
I’ve been using the ISY binding with OH2 and everything works great! However, since I’m fairly new to OpenHab, I decided to try OH 3 as this is the future and I would rather spend my time learning the newest version. But, the OH2 ISY binding does not work with OH3. Are there any plans to update this binding??
Thanks
David
1 Like
I’ve had to federate OH2 running only the ISY binding with OH3 to facilitate migrating mostly to OH3. This works, but not the best use of resources and would really like to see the ISY binding migrated. The ISY v2.4 works quite well and I don’t thing would take much effort to migrate, but it still requires a maintainer to do it. I thought about trying myself, but I would be starting at ground zero. Here’s hoping someone with the right skills steps up to do this.
Hi John,
I too have thought about trying the migration myself but I would be starting at ground zero also. The Guide: Binding development changes for openHAB 3 (from 2.5.x)
indicates what needs to be changed for the binding to work with OH3. I’ve made the changes to the source files but failed miserably when trying to re-compile. Eclipse and Maven are new to me and I have no idea where to start. I agree that someone with the right skills will hopefully step up.
I’m in the same situation and got about as far as you with a failed compiled. I did see Git that the ISY is on the list for consideration to move to OH3, but no timeline. I may try to prod this along on Git if I can find the right person to nudge. If enough of us express interest it may happen, and happen sooner than otherwise. I know there is a new Insteon binding for OH3, but that is no substitute for ISY in my opinion.
I’ve had my ISY 994i integrated with several Insteon and 1-wire temperature devices for maybe 5 years now and haven’t had any issues. I currently use MobiLinc which I would like to replace with OpenHab. I agree on the Insteon binding part. Plus I believe I would have to purchase a PLM device to communicate with the Insteon devices.
The list only shows the state of any work done. It’s not a planning list nor a list for consideration, other than people may look at it to see if something is done.
What version of this binding is this? Is the one where the link of source code is shown on the list?
thanks for the clarification regarding the list. There is source code on GIT [ GitHub source Search · ISY binding · GitHub 1 and another [openhab2-addons/IsyRestDiscoveryService.java at master · HentschelT/openhab2-addons · GitHub]( GitHub source Search · ISY binding · GitHub 1 and another [openhab2-addons/IsyRestDiscoveryService.java at master · HentschelT/openhab2-addons · GitHub)
There is is also a link source code in the list. The binding was never merged into OH2 but was available on the Marketplace. It does auto discovery and works quite well in OH2.5.x I believe the binding is listed as 2.3 or 2.4 depending on the dl location.
This is the version I’m using with OH 2.5.x and it works great…
For those of you having trouble with the binding, I have written an ISY 994 - Homie bridge to use the ISY with Homie and OpenHAB. I have been using exclusively. Just logged on to OH and its been running 160 days without issue.
I found the ISY binding to intermittently fail.
@mjcumming is your binding an OH3 or OH2.x? Are there any special ISY994 firmware requirements to use the binding? The OH2.x version of the ISY binding that I am currently using has been stable for the most part, although sometimes multiple restarts are needed to get all of the devices online, but once there it seems fine. I’ver been using it for about 2 years. However if your binding is OH3 with auto discovery, I’d be interested in taking a look at it. Where might I get a .jar add-on and setup instructions? I would imagine that setup is a bit more involved given that it is MQTT.
No binding unfortunately. It used the MQTT binding and requires an install of the bridge from PyPi.
Its not as nice as a built in binding but its robust and easily extended since its written in python.
Thank you for the clarification. I have quite a few devices so for now I think I’ll stay with the 2.x binding.