The binding reports the correct values - so something must be happening when convert F to C. A work around would be to create a virtual temperature item and use a rule to set that value when the actual temperature item changes.
It shouldn’t be converting F to C. The binding returns the temp in whatever format the panel is set to (C or F).
Brian, if the binding is converting the omni temperature format to the C or F based on the panel setting, perhaps its just returning an integer?
I assumed that the Binding was dropping the .5 degrees
see snip from Paper UI below. The “Temperature” Channel does not report any decimal points.
The core jOmniLink library returns temperatures as an int. Good thought @mjcumming.
If someone wants to open an issue here I can tackle it at some point.
Hi! New to OpenHab and trying to get things working with my Omni system. I was pleasantly surprised to see the great support for audio and locks via Omni but puzzled about the current state of Units? No longer working with version 2?
I’m running a mix of old Lightolier Compose and Z-Wave devices. I couldn’t find release notes but have tried using things support for UPB, ALC, Rooms and PLC to see if I can get things working. I can use UPB to do simple on/off control but can’t find a way to access lighting scenes with Compose. Any tips or hints?
Looking through posts I see others looking to use non-UPB lighting systems and Brian’s recent posts about working on Units support. From a past life, I was familiar with the Omnilink protocol and I’ve read a bit through the jOmnilink code. Lighting was pretty genericized and it seems like working unit that would allow passing an integer for state would control dimming, as well as scene based lighting system via the Omni without need to do much specialized. Is this something that might be coming? (Or could be incented with a bounty?)
Any help or future roadmap infor would be appreciated.
Hi - I am still working on generic units support, but it will require some refactoring. I don’t have Lightoiler on the agenda currently. Once we have generic support we can look at how hard it is to add specific lighting subsystems.
Quick update.
I have completed the code to support generic dimmable units of the following types:
- Centralite
- RadioRA
- ViziaRF (ZWave)
- Compose
Additionally:
- Added support for output type units
- All unit types also now support on/off for seconds/minutes/hours
- Support for UPB status requests
This was a pretty major change to how units are handled. While the code is complete, I will not be able to test the code for at least a week.
1 Like
That’s great. I should be able to play around this weekend I can test Zwave lighting and units. I assume instead of upb channels we now have zwave and unit channels in the items file.
It will be a new generic type “dimmable” that should work across centralite, radioRA, ViziaRF cand compose.
I haven’t switched my main system over to it, but some preliminary testing indicates that it still works. If someone with Zwave/centralite/radiora or compose could test the release I would appreciate it… once it looks good I will submit a PR.
You can download the test version here: https://github.com/boc-tothefuture/openhab2-addons/releases/tag/dimmable
I moved my main system over to it yesterday. Appears to work fine. If someone with zwave or one of the other systems could test that would be great.
@jlekhter or @emmsquare ?
I’m working on installing a test system, I installed my main system from the paper ui and the marketplace and when I put this jar file in the addons directory, openhab throws errors. Not sure I want to delete the marketplace binding and affect the house.
Is there an easy way to replace the jar file the PaperUi installs? I can’t seem to find it for some reason. Dumping the file into the add-ons directory alone isn’t working. I think I have to actually uninstall the old binding which I’m a little nervous to do.
I took the plunge and just installed the new binding on my home system. The good news is that it all seems to still work as expected but I will keep validating that over the next few days.
The units and zwave mostly work as expected. I updated a few items to use the dimmable channel and also updated a few items to use the output channel for my backyard lighting. When I control everything from the basic UI, I am able to get the appropriate lights on and off. They also register as going on and off in snaplink and I see the correct messages and state changes in the openhab logs.
However, when I change the state of the items through snaplink, neither the output nor the dimmable item seems to get the update. I dont see anything being logged in openhab either.
I’ll be pretty busy through Apr 15th, but can try to test sporadically if you want some specific log info.
And thank you so much for even taking the time to get these things working! I’m excited that its pretty close.
Thanks for testing… I see in the code where I missed updating for outputs and dimmables. I updated the code on github. If you could drop your new plugin in and tell me if updates work that would be great.
Ok – had a chance to install the new version. Looks like Zwave is working fine now, but outputs still have the same behavior. Changing the state using the basic UI updates Snaplink, but changing the state in Snaplink does not seem to trigger an event in the log or the basic UI.
BTW – all my zwave devices are outlets so they are either off or on, unfortunately I cant test truly dimming them.
one more thing – nothing to do with these changes, but I own a Lumina vs an Omni and it appears that the lumina area is looking for a channel called lumina_area vs. area. As a result I cant get any of the Home, Away, Party settings. Below are the log references:
2019-04-09 20:54:33.678 [WARN ] [ore.internal.thing.ThingTypeResource] - Cannot find channel type: omnilink:lumina_area_command
2019-04-09 20:54:36.629 [WARN ] [g.discovery.internal.PersistentInbox] - Cannot create thing. No binding found that supports creating a thing of type omnilink:lumina_areaI can’t replicate what you are seeing with outputs. When I change them in snaplink, the changes immediately show up in the paper UI.
Looking at the code, we don’t support Lumina areas. I can add the code for that, but would not be able to test it.
I can test the Lumina code. I’ll retest the units tonight. Maybe I need to restart openhab or check my item configuration.
Did you use auto discovery for your outputs or specify it manually?