Are the switches cross linked to the PLM? In other words: are they both controllers of and responders to the PLM? If they are just responders, the PLM can still command them, but if they cannot control the PLM it won’t get notified of status changes (which should happen immediately no need to wait for poll)
They aren’t cross linked yet, I’m going slow on setting things up, want to make sure I understand exactly what openHAB is capable of. I thought that the polling would update the item state, does it not? I can’t imagine why openHAB would poll if it wasn’t to ensure the correct state…
Hmm, interesting. I’m not sure what changed but now it is updating the state after polling…
That is the intent of polling but not sure if it will work sans cross linking. It might, just not sure. Frankly the polling is just to catch something it may have missed. The direct update is what you really want. Also, you really should have the devices cross linked whether or not you use openHAB.
Thanks for your help Tommy, looks like all is well now. Polling is picking up state changes without cross linking. I’ve been monkeying around with Insteon programming since around 2007, I go back and forth on whether cross linking with the PLM is good or not. I haven’t really cared much to know if the device is on or not up until now, so cross linking just created more noise. It is kind of nice to see what’s on and what’s off though, I think I’ll enjoy openHAB. Thanks again for your assistance!
I don’t know if you are aware or not, but InsteonPLM is a OH1 binding.There are plans on dropping support of OH1 bindings in a future release of OH. Unless InsteonPLM is rewritten as a OH2+ binding support will be going away. See Removal of the OH 1.x Compatibility Layer for more details.
No kidding? That’s both disappointing and intriguing. The current binding kind of “missed the bus” on a lot of features that should have been included, but something is definitely better then nothing. I guess I’ll have to look into writing a new binding.
2 Likes
That is not at all a complete description of consensus on that thread.
Yes, the OH 1.x compatibility layer will go away which does mean that any OH 1.x binding will not be supported on OH 3 (which is at least a year away).
But OH 3 will also support a federation capability that will let you continue to run your OH 1.x bindings on an instance of OH 1 or OH 2 and those Items that are configured there will be represented in OH 3 as well.
Support is not going away completely. You will be able to continue to run OH 1.x bindings into the future.
You may not like this approach, but to say that support is going away is incorrect.
That would be fantastic if you are willing to create a 2.x binding. It is apparently a much used but much neglected binding.
But what Rob said is not entirely correct. Native support for OH 1.x bindings will not exist in OH 3. But there will be a way to support them by using an older OH instance and federation of the event buses. OH is not completely leaving OH 1.x binding users behind.
I can;'t remember who, but I believe there is someone who a few months (maybe a year) ago said the was working on a 2.x binding. Not sure where that got to.
1 Like
I poked around a little and see that @Burzin_Sumariwalla posted back in August/18 about starting to write an Insteon binding for openhab2.x. You may want to touch base with him as to not duplicate efforts. There may be another as well, I thought for sure it was monger ago that last August I saw this but I may be wrong.
Awesome, thank you!
I’ve been looking at the possibilty of writing a 2.0 binding, too, because I’ll need it. I haven’t made a lot of progress, because the IDE’s been unstable and because I’m having to get a test environment set up before I can start (need a PLM to fiddle with, don’t want to stop my main openhab to test with) and that’s taking a little doing. And I have other things on my plate.
I do think there’s some interest in a v2 Insteon binding, if we can just get ourselves organized and get one going.
The commentary in the v1 binding makes me think it won’t be full of exciting auto-discovery and things, but continued first-class support will do for me!
Also, I didn’t think the Insteon binding updated while it was running; I thought you had to restart the binding to get it to update the list of devices for openhab. Now I don’t remember where I saw that.
Support is indeed going away for the current binding in OH3. Yes you can use a workaround as you describe, but that doesn’t mean its supported anymore. It’s just a way you could make a OH 1 binding work with OH3. Plus the approach will not work very well on lower power arm based devices.
The way you originally stated it implied at the release of OH3 the bindings are rendered unusable, which is not true.
They are unusable with OH3, thus not supported. A hack by using OH1 or OH2 still doesn’t mean its supported with OH3.
As long as the “hack” exists, the binding is still usable. To imply otherwise is a false statement.
If you look at my original comment, I said support will be going away which is true. This sort of attitude is what has driven people away from wanting to contribute anymore (including myself).
Well, the opportunity existed and continues to exist for you or any other contributor to pick up suppory for the compatibility layer and support it going forward.
The opportunity also exists for any developer to build a 2. x version of any binding that is important to them.
But to demand other developers do work they don’t want to do so that you don’t have to do work you don’t want to do on an open source project is IMHO a pretty shitty attitude itself.
Kai isn’t our slave. He’s the only person who has maintained the compatibility layer since the beginning. He is no longer willing to do the work and no one has volunteered to take it up. So either step up and take it on yourself, find and /or pay someone else to do it, or be greatful that there will at least be a way to not lose the ability to run your 1. x bindings.
If that attitude drives contributors away then so be it. But Kai has every right to choose what and how he contributes to this project as you do. What right do you have to dictate otherwise?
I’ll say it again. Step up or shut up. Anyone can save the compatibility layer. All it takes is volunteering to suport it. No one has stepped up so it’s going away. It’s a simple as that. I’m sorry it’s such sn inconvenience for you. But it must not be that much of an inconvenience because you aren’t doing anything about it except bitching. Or is it you feel intitled to dictate what everyone else donates to the project so you can avoid the inconvenience?
To the further readers, be more like @cdoc83, @tommycw10, and @Laufeyjarson who, when faced with lack of the compatibility layer responded with “what can I do” instead of “those damn developers don’t care, in going to take my ball and go home.”
@rlkoshak, wow your panties are in a bunch! Your exact response and attitude is what has pushed developers away and not want to contribute. I never asked or expected @Kai to continue to maintain the OH1 compatibility layer.
Again, all I stated is support was going away in a future release of OH to make InsteonPLM users aware of it.
