I’ve seen a couple of brief mentions around, but is there any current development going on for a UPB binding? I’m very new to openhab and would like to add some support for the few UPB switches that I have. I’m willing to collaborate, but otherwise I can make something myself.
I am interested as well. I am at a total loss when it comes to developing bindings for OpenHAB, but I am more than willing to offer what I can. Currently, I use HomeSeer to interface with my PIM to control the switches in my house. The way that the plug-in for HomeSeer works is by taking the configuration file that upstart creates and exports, and then using that to know what scenes are available, what switches are available, what each of them do, etc. It works really well, but I don’t really know much about how it’s implemented. I would think we should start there with our approach for OpenHAB. We can take the exported configuration from upstart and see what that file contains and how we can leverage it.
ok, well, I’m not sure what use UPStart’s config files will be at this point. I suppose there might be some use in openhab2. I’ve written a binding that is functional now. I just need to do up the documentation on the wiki and hunt down some stability issues before I submit a PR.
Hi Chris. What is the status of your PR? I am very interested in UPB in OpenHAB.
I can not help with development but I am very willing to do any alpha or beta testing. I have an environment with many UPB Simply Automated units.
Thanks.
Chris, The way that the plugin for HomeSeer works is that it takes the output from the .UPE UpStart file, and then parses it into HomeSeer to essentially create a replica of what you have set up in UpStart (i.e. - What Devices, Names, Rooms, Links / Scenes, whether or not the switch is dimmable, whether or not to expect the light level to be returned, etc.). It’s a pretty slick implementation. I would think something similar would be very handy here.
I submitted the PR on Jan 23 and it is awaiting review / approval (https://github.com/openhab/openhab/pull/3883). There is a link to a test JAR in the PR comments.
Yes, I understand the value in such a feature. However, OpenHAB doesn’t allow the dynamic addition of items from a binding (as far as I am aware). They have to be manually entered into the OpenHAB configuration file. I believe that OpenHAB2 does have this feature, so it is something to consider for the future.
Hi Chirs,
I have been playing around with your UPB binding. Not sure if its intended or not, but it does not seem the switch retrieves its initial state. Meaning, when I open the app and the light in a room is on - to turn off the light I need to toggle the switch in the app to on and then toggle back to off. Is this a known bug? It would seem like an easy fix to call from the PIM the state of all switches.
Thanks very much for putting this together. Cheers.
Are you still fiddling with the UPB binding? One important thing to know if you didn’t already – UPB devices can be configured as either “verbose” or “silent.” In silent mode, they receive commands and act upon those commands, but they do not send out any response or update. No confirmation as to what the status change is. (On / Off / Dim etc.)
They can also be configured to be verbose, so that a UPB device sends out a status update on the UPB bus with every state change of the device. Clearly this is preferable for home-automation purposes. The only downside is that, for whatever reason, due to how the UPB hardware is implemented, there is a slight audible “sizzling” sound that comes from the device during the ~0.5 seconds it takes to send out a status update.
A lot of people leave the devices in “silent” mode to avoid this unsettling hiss/buzz sound, understandable because the sound actually resembles an electrical device starting to fail, it sounds like sizzling or even internal arc’ing. But it’s not failing, it’s just the noise created when the device generates the UPB carrier wave to send out a message. I don’t recall exactly but I believe the carrier wave is in the kilohertz range, and certainly the modulation is fairly low frequency because the protocol itself only handles 4800 baud data rate. Combine that with a very considerable amplitude (I believe it’s at least 40 volts) and the conditions are ripe for audible resonance somewhere in the device itself, perhaps in an isolation transformer or some such.
Anyway – long and short: if you can tolerate the “sizzling” sound with verbose mode enabled, it should be much easier to get reliable integration with OpenHAB.