Plugwise binding

Add-ons Bindings
, ,
22

Do you mean with updating openHAB editing/saving .thing files?

Yes that is a known issue. Eclipse SmartHome does not provide an interface to easily find custom named devices. You can use one of the following workarounds for this:

  • In the “Inbox” click the ignore button on the discovered items. The ignore button is the eye with a backslash.
  • Use as thing ID the full uppercase MAC. This way the discovery service has a way to find the items you defined in .thing files.

Another way to resolve this could be by enabling/disabling background discovery for the Plugwise binding with the smarthome:discovery command. But some binding code changes need to be made for this to work.

23

A new version of the binding is now available with the following additional functionality/bugfixes:

  • New configuration parameters for all devices, for a complete list see the Thing Configuration section in the documentation.
  • Because the energy measurment interval is now configurable via a parameter, the lasthour and lasthourstamp channels have been renamed to energy and energystamp.
  • The offline/online behavior of the Stick has been improved, exceptions are no longer thrown and it will retry to communicate with the Stick instead of being offline forever. I’ve also seen it recover from unplugging the Stick and reinserting it.
  • The binding automatically detects Sticks once every 3 minutes.

The opening post contains the updated URLs to the most recent binding JAR and documentation.

People using the previous test JAR (downloaded before March 8th, 2017) should do the following to upgrade:

  1. Remove/deinstall the old binding and JAR
  2. Download/install the new binding JAR
  3. When the new device configuration parameters are missing from your existing Plugwise Things, remove these Plugwise Things and readd them.
  4. Update your .items files so the lasthour and lasthourstamp channels are replaced with energy and energystamp.

On recent builds of openHAB 2.1.0-SNAPSHOT (#828 or higher) you can also install the updated binding via the new IoT Marketplace.

https://marketplace.eclipse.org/content/plugwise-binding

24

I’ve made a new JAR (2.1.0.201703290000) that fixes some minor issues like exceptions and the serial port not properly being set during Stick discovery. It should also optimize the number of messages being sent when the binding is started. It can again be downloaded from the opening post or using the IoT marketplace.

I ran into this myself now when using a .things file with openHAB 2.0.0. It looks like this issue is fixed in recent 2.1.0-SNAPSHOT builds of openHAB. It was fixed by ESH PR #3088.

25

Running openhab2 on a raspberry pi (2) with an official plugwise stick. I am trying to have it connect to my plugwise stealth which used to be connected to the plugwise stretch which has died on me a while ago.

I like to do things by hand so i copied over most of the example configuration (taking “Fridge” and replacing it with “Solar”. However my stick seems to have trouble getting initialized. I get no errors in my log file but if i load up paper UI and go to config --> things i see that my stick is stuck on “initializing”. I have verified with dmesg that it is bound to /dev/ttyUSB0 so i’m at a loss at what it could be. I have the serial binding also installed.

I am at a loss as to why it will not initialize. :frowning:

26

Did you also add the user running openHAB to the dialout group so it has permission to access the serial port? When you use openHABian than the permission should already be done. On Raspbian you’ll need to do this manually, e.g. with: sudo adduser pi dialout

Was the Stick also used with that Stealth? If not you will need to factory reset the devices and setup a network with Source (which requires a valid license). Migrating back from the Stretch to the Stick is a scenario that I have not tested. Other people might also be interested in knowing if it works and how to get it working. :slight_smile:

Increasing the Plugwise Binding log level may also give some clues about what is going on:
log:set trace org.openhab.binding.plugwise

Then check the logging with: log:tail
And exit the logging with CTRL+C

Afterwards you can reduce the log level again with:
log:set info org.openhab.binding.plugwise

27

I’ve tried plugwise-2py and it also seems to get a timeout while trying to connect to /dev/ttyUSB0. It’s very weird. I checked groups for the users that i tried to connect from and they’re all in the dialout group.

my stealth used to be in the network with my stretch, but the problem right now seems to be getting commands going at all over the plugwise stick. I bought it brand new so i’m not sure if it should be configured somehow or if i have to use source then. I can’t seem to find people with similar problems. I’ll specifically try to search for that myself and see what i can do about it.

Any problem doesn’t seem to be related to your binding is as much as it has something to do with the communication. I will try to use the specific trace level on the binding itself see if it gives me anything useful.

28

The group permissions are only applied when the user logs out/in again. So if you haven’t done that it is also worth a try.

When it was part of a Home Start pack I would also check if it works with Source on Windows. There should also be a license for Source in that pack.

Plugwise Source also works when you run Windows in a Virtual Machine. But it may be a bit tricky to route your Stick to the VM if you haven’t done this before. I usually run Source on Ubuntu in a Windows 10 VM using KVM. :slight_smile:

29

Thanks for your help. I seem to be at a bit of a fork in the road. I got the plugwise stretch + stealth when my solar panels were installed. I never bought home start or any additional plugwise component. My stretch is broken and outside of warranty and i don’t really want a replacement Stretch. All i want to do is read my solar panels so i thought simply buying a stick would be enough.

I have tried connecting the plugwise to my pc (ubuntu) and run plugwise2py. It seems to at least not crash but gets stuck on an arbitrary error that i am unsure is a problem with the communication of my pc to the stick or maybe the stick is just out of range of the stealth, or something else is amiss.

So unfortunately I don’t have a Plugwise Source license. I could send back the plugwise stick i bought and buy the home start set that includes a stick as well but it’s a bit of a steep price. Alternatively i can have a bluetooth dongle built into my inverter for that exact same price and be done with plugwise stuff.

Thanks for your help so far, i don’t want to derail this topic into something it’s not.

30

I think sending it back would be the better option especially since you don’t use any other Plugwise modules. The Stealth is probably a Stealth+ (grey back) which may give issues because it is not standard to use with a Stick. Usually a Circle+ is used and I don’t think using a Circle+ and Stealth+ in the same network is possible.

31

Today the new openHAB 2 Plugwise Binding got merged into the openHAB source tree. :slight_smile: :tada:

This means it will soon be part of the openHAB 2.2.0-SNAPSHOT nightly builds. The old openHAB 1 binding will still be available as a legacy binding.

32

Wouter, I installed the 2.3.0 SNAPSHOT from december 26. I did not use Openhab2 since more than a year. The Plugwise binding is much improved since than. Thank you very much for that. Autodiscovery prevents trivial errors, but I still need some help. I have 19 circles, which are functioning well with the latest binding, but I get the following message about every 3 minutes:
2017-12-27 18:46:42.556 [WARN ] [gwise.internal.PlugwiseMessageSender] - Error sending: No ACK received after 1 second: 000AB43C

2017-12-27 18:49:48.001 [WARN ] [gwise.internal.PlugwiseMessageSender] - Error sending: No ACK received after 1 second: 000AB43C

2017-12-27 18:52:53.431 [WARN ] [gwise.internal.PlugwiseMessageSender] - Error sending: No ACK received after 1 second: 000AB43C
The characters before 000AB43C are ENQ,ENQ,ETX,ETX.
Do you have a suggestion how to go a bit more in depth to find out the cause of these warnings ?

Gert

33

@Gert it uses that message to discover the Stick. Does it work well besides those warnings? The binding may just need some tweaking to suppress such warnings during discovery.

34

@wborn OK. Thank you for the quick response. I will ignore these warnings for the moment. I have more serious problems with other bindings and the Plugwise circles do what they should do.

Gert

35

@gert_konemann the warnings should be fixed with PR #3098 that got merged today. It will probably be part of the next OH 2.3.0-SNAPSHOT build (#1178 or newer).

36

Thanks, Wouter. I will try. Probably next week.

Gert

37

Just to let you know (maybe normal, i don’t know), i’ve just tryed 2.3.0-SNAPSHOT #1178 today and nearly nothing related to plugwise was working, despite no particular error logs (no power sent for example, i was just able to find some “last change” timestamp on start in logs, then nothing more). Moreover some of my devices weren’t detected anymore. Back to 2.2.0 now where things are better (Power found again, all devices found again).

38

Thank you @wborn for this binding. I have a lot of circles I’m using together with OH 2.3, latest snapshot. I notice OH get unstable and hangs sometimes. The folowing is logged in the openhab.log:

2018-03-20 21:29:24.866 [WARN ] [gwise.internal.PlugwiseMessageSender] - Error sending: No ACK received after 1 second: 000D000D6F0002778E35470F
2018-03-20 21:28:54.672 [WARN ] [com.zaxxer.hikari.pool.HikariPool   ] - 51s139ms943μs570ns - Thread starvation or clock leap detected (housekeeper delta=yank-default).

During this Thread starvation OH is unresponsive. And once it has happend a lot of other things start to work badly. Is there something that can be done about this?

Thanks!

39

@bastiaan_van_h nice to hear you find the binding useful! :slight_smile: I haven’t seen these issues myself with the binding so most likely something else is making your OH unresponsive.

There is another topic where people report heavy CPU usage including the “Thread starvation or clock leap detected” logging: Openhab2 java cpu 100% . I’ve added some replies to that topic on how to find in OH the threads that are using the most CPU time.

40

Hm, interesting. I used some guidelines from that thread to look at the CPU load on my OH.

Id Name State CPU time Usr time CPU %
142 Thread-39 RUNNABLE 1043292 707070 41,32045879
258 HTTP Refresh Service TIMED_WAITING 203098 137980 8,043867431
71 openHAB-job-scheduler_Worker-1 TIMED_WAITING 133843 100190 5,300964798
72 openHAB-job-scheduler_Worker-2 TIMED_WAITING 130746 97750 5,178305504
144 Plugwise MessageProcessorThread WAITING 119454 105320 4,731076328
87 ESH-OSGiEventManager TIMED_WAITING 97400 77490 3,857609074
286 ZWaveReceiveThread RUNNABLE 58110 39710 2,301495517

Thread-49:

Thread 142 Thread-39 RUNNABLE
Stacktrace:
gnu.io.RXTXPort.eventLoop line: -2
gnu.io.RXTXPort$MonitorThread.run line: 1611

I have two USB dongles, one Zwave and one Plugwise. When I enable debug of the plugwise binding I see a lot of updates per second. So perhaps this could cause high cpu time. It doens’t explain the threadlocks, but does explain why my OH is reguarly slow.

Edit: I have 25 Circles in my network.

Is it normal that the RXTXPort utilizes so much CPU time? Any other thoughts?

41

There is a lot of polling going on to get the state from Circles. You shouldn’t enable debug logging unless you have a good reason. Generating debug logging will also consume a lot of unnecessary CPU cycles and disk writes.

Other functionality that increases CPU usage is:

  • Decreasing the update interval of channels from their default values to get faster updates. Especially for larger networks (20+ Circles) a lot of polling will cause message delays because they are put on a queue and the network has a limited throughput.
  • Creating items for channels you don’t really use. This will cause unncessary polling. I normally don’t use the clock or realtimeclock channels.

I’m using the binding with a network that has 30 Circles and additional Scans and Senses on default settings. So it should also be able to handle a network with 25 Circles.

The CPU % used by the serial communications thread is relative to that of the other openHAB threads. So if all openHAB is doing is Zwave and Plugwise communications it could have a high value. Do you run openHAB on an embedded board like a Pi3 or something more powerful like an Intel NUC?

Because there is also the HikariPool I assume you are also using persistence? Periodically databases may perform maintenance tasks such as vacuuming which can cause hangs. Is only the openHAB java process generating the CPU load? E.g. on Linux you could check with the top command what is else is happening when OH is slow.