i’ll give it a try too… I have about 25 of those plugs, but were having issues in the past, so replaced them with Fibaro plugs… And just recently i was thinking to buy more Fibaros and finally sell those plugwise ones which I have lying here for abut a year now, but perhaps your binding works better for me than the OH1 one I’m not sure yet i will stick with them even if it works, as meanwhile i have a huge zwave network and also plenty of hue stuff, and it might be more reasonable to extend these then add yet another network. Too sad plugwise cant be convinced to make their devices “real” zigbee with a firmware update…
In your original collection of ideas i read you also want to be able to retrieve historic data, is that working already ?
I once also thought about replacing all the Plugwise hardware for an easy fix. The Fibaro plugs are a good alternative and they are a bit more compact too. However, I took up the software challenge and it now works pretty well for me.
With a good stable OH2 binding they will be worth more.
It seems they are busy with targeting regular consumers and not the Home Automation community. Product diversification with air conditioning and smart thermostats seems also on top of their list. Their older portfolio seems to suffer from this. IIRC the Circles were introduced in a time where Zigbee was all the hype and only a handful of ZWave products existed. I can imagine a lot of their code needs to be rewritten would they ever switch protocols.
Only the last hour energy value is currently retrieved from the historic data entries (like in the OH1 binding). It’s an easy code change to retrieve all available log entries and dump them to something like a CSV file. I use it this way myself for validation and retrieving entries I’ve missed when my openHAB instance was down for some reason.
Using a CSV file or creating a mechanism to retrieve the data via channels is not the most elegant solution. So I’ll be looking into if it can be done by implementing a persistence service.
Surely interested!
I was planning how to move to the OH2 style of defining things, this will certainly help.
I really like to thank you for the plugin, it makes these plugs really worthwhile (they’ve been super reliable and been doing their job for years).
I just tried to install the binding, but stuck it seems.
I downloaded the jar file, moved it to the addons folder, changed ownership to openhab:openhab and permissions to 644. After a restart of openhab (before I didnt see anything in the logs i think) I get the following:
2017-02-25 17:05:05.766 [ERROR] [org.openhab.binding.plugwise ] - FrameworkEvent ERROR - org.openhab.binding.plugwise
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.plugwise [215]
Unresolved requirement: Import-Package: gnu.io
at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1561)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
added the zwave binding as well, this solved this dependency… so far the binding is working fine, but i’m not sure yet if and how i will continue to use my plugwise devices…
The Plugwise Binding also needs to have the Serial Binding installed which provides ‘gnu.io’. So that is what caused the exception. The Z-Wave Binding probably also depends on it, so that is why it got fixed. I’ll add it to the opening post.
In the OH1 binding you could only use one Plugwise Stick (and Plugwise ZigBee network). You could also configure only one serial port. Because in the OH2 binding the Stick is implemented as a Bridge Thing, you can connect multiple Plugwise Sticks to your computer and use them all at the same time. I don’t think there will be many users of this functionality though.
great work with the add-on. I’ve a still a problem to get it running.
I use openhab on a raspberry pi 2 with the zwavemee adapter at the io pins. when i add the plugwise stick as a thing the system told me that /dev/ttyUSB0 is not available, but /dev/ttyAMA0 (which is the zwave adapter): Serial port ‘/dev/ttyUSB0’ could not be found. Available ports are: /dev/ttyAMA0
i’ve installed the serial binding but without success. Do you have any idea what i can test now?
Does lsusb show the Stick? The following device in the command output shows that the Stick is detected:
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Does the standard (OH1) Plugwise Binding work for you? You might need to uninstall it when it is already activated. This is part of Step 1. of the opening post.
When I first started using a Raspberry Pi it only detected the Stick after a restart.
I have 2 starter kits, one seems to work fine, but when i take a circle from the second kit and add it to the network it does not seem to be detected. If i enter it manually it does not show online either, any ideas? i did notice when i added the MAC manually it shows only the last few digits in the overview, maybe its a bug or maybe it does not mean anything i dont know.
When Circles were already part of a network (the starterkit) you might need to be reset them before you can add them to another network (the other starterkit).