How does it know 20.1 C or 20.1 F? Both are reasonably common temperatures to be encountered.
Sorry, I don’t know. Locale perhaps?
1 Like
Actually yes, it is locale, described here:
Units of Measurement
1 Like
I can try to replicate what the core is doing, that is considering a default unit if no unit is provided. Just have to find how and where it is implemented in core framework or if we have an utility class for doing that.
@DavidR : sending a decimal value without unit to an item that expects a unit has no sense IMHO.
I have no clear idea how the core framework is handling that case.
By the way, I updated the binding to translate this value to the core framework. So it should solve your problem … even if the real problem is more your way to update these channels.
1 Like
The change is merged. So it should be included in next snaspshots.
Wow that was fast!
I’ve already changed my python script to send units, but I’m sure your recent change is the correct behaviour.
Thanks once again for the great work.
I’ve been using the Binding for almost a week now and have been generally impressed with its functionality. However, I have noticed an issue that continues to plague its use in my setup. I am trying to link my OH2 2.5.9 setup with OH3 M3. Both are running in Dockers. OH2 has been working flawlessly for almost 2 yrs now. I have an extensive ISY/Insteon installation that OH2 automates and for which there is no OH3 binding as of today. I am able to link OH3 to OH2 and control OH2 Things/Items from OH3. However any changes made to Items using OH2 are not reflected in my linked Items in OH3. Going the other direction OH3 to OH2 works fine and changes are properly reflected in both OH2 and OH3. My understanding is that the binding is bi-directional, but in my setup it appears to only be OH3 -> OH2, not OH2-> OH3. If I restart OH3 then changes made in OH2 prior to the restart seem to be reflected, but no real time updates seem to happen.
Any ideas what I may be doing wrong.
SOLVED: As of snapshot 2061 this has been resolved.
John that is correct. I’m not sure if it would not be better to start a whole new thread to troubleshoot your issue as it may be related to your use of ISY/Insteon or may be directly binding related (disclaimer: I know nothing about ISY/Insteon)
Minimum suggestion however is to include what platform each of your versions run on (are they on the same hardware or separate maybe on VMs ect) and all other related info to help troubleshoot
1 Like
Have you had a chance to try OH3 M4 yet? I’d be curious to know if the recent changes to the Remote openHAB Binding have cured this.
No because I have not yet fixed the problem.
Thank you for developing the binding! This is really what I have been needed, so far I have used the eventbus ( MQTT 2.5 Event Bus ).
What is the current status? OH2 -> OH3 is not working, but I guess OH3->OH3 is working?
How about OH3->OH2 ?
The reason why I’m asking is because I’m rebuilding my bindings for OH3, and I have a couple of RPIs running OH3 as testing environment for the bindings and I’m hoping to be able to link them back to my main OH2 prod instance.
BR, S
I am not sure if I understand you correctly, but the binding will have to run on a OH3-Server. It can query other OH3 servers and OH2 servers and feed their items to the OH3-Server it runs on. So your main OH-Server needs to be OH3 and it can gather data from any OH-Server in your network which at least is OH2.x or OH3.x.
I misunderstood then, I thought it could run under OH2 as well.
Regards, S
I’m still curios what is working and what is not working, since @John_Siemon stated OH2 changes are not reflected in OH3 using the binding. I’m asking before I go full on mqtt to share stuff between my instances.
Regards, S
@Seaside, I would wait before going the mqtt route. I initially started down that path, but that is a lot of work if you many Things. Keep in mind this is only M3 and the binding remains a work in process. Further even after OH3 is released, it is likely to have issues that will need to be corrected in point releases. In my case I have a very stable and extensive OH2 install and no immediate plans to convert my production system to OH3 until OH3 has been out for a while and the dust has settled. At this point I have confidence that the Remote OpenHAB issues will be resolved, but only time will tell. At this point I am patient.
Final point is that I am having issues with ISY/Insteon Dimmers in particular not updating bi-directionally. Simple switches appear to be ok in my limited testing. Depending on your devices you may not have an issue with the binding as is.
1 Like
I just want to be clear, I did not develop the binding. I don’t want to take credit where credit is not due.
1 Like
I mentioned you in the context of the eventbus. I have updated the original reply with a link to the eventbus guide instead.
Regards, S
1 Like
Regarding the specific problem encountered by @John_Siemon with unofficial Isy binding and the remote openHAB binding, the discussion now continues in Github.
1 Like
Great work !!!
I’d like to slowly migrate to OH3.
Is it possible to run OH2 and OH3 on the same server (w/o docker or VM) and still access OH2 via Paper UI / Basic UI and OH3 via Main UI while connected with this binding?
… or in other words… how to make a clean setup of OH3 on the same server while OH2 remains „as is“. I imagine that both instances would use port 8080.
Then I could connect them by this binding and slowly migrate.
(I‘m using openHABian 2.5.10 on NUC at the moment)