Plugwise Plugs component

I’m unhappy to read it doesn’t work for you anymore.
Could you please check the contents of

/config/.storage/core.config_entries

It should contain only single domain for the plugwise_stick

And can you also validate if the file

/config/.storage/core.device_registry

it should not contain duplicate plugwise devices either.

1 Like

Thanks for caring :+1:

I think I fixed it! Began with a restore of an older snapshot earlier today, but that resulted in other issues where the thread kept dying. Ultimately rolled back to my current snapshot, but had the ‘multiple thread’ issue again. Decided to set global log level to debug and then found another mention of plugwise in the logs. It was an older HACS plugwise integration from cyberjunky. Removed this completely, reinstalled plugwise_stick into custom_components and restarted HA. This time it all worked again :slight_smile:

I don’t understand how this could have been the reason for the issue, but happy everything now works with your latest code.

PS also checked the files you mentioned for duplicate entries in my file backup from yesterday, but only one mention of plugwise in .storage/core.config_entries and no devices in .storage/core.device_registry

1 Like

I’ve made some progress and changed the integration a bit.

  • It now automatically adds a sensor for each meassured value. Some will be default active (enabled) and some will be disabled. If required you can enable/disable sensors.
  • Fixed closing port issue which caused an issue when you enable a sensor.
  • Fixed the warning messages mentioned by @koter84 when you disable sensors/switches
  • Add experimental support for Stealth devices as I am not able to test because I don’t own one

You can download the new custom_component here

2 Likes

I tried to install plugwise but it does not work. These are the steps I took:

  • installed the library: pip3 install python-plugwise
  • copied contents of plugwise_stick to the custom components directory
  • changed the port = “/dev/ttyUSB0” in the example.py wich is the usb port of the plugwise circle stick
  • added the following to the configuration.yaml file:
    switch:
    • platform: plugwise_stick
      port: /dev/ttyUSB0
      circles:
      CirclePlus: 000D6F00019DB8A0

When I run the example.py (python3 ./example.py) I get the following:

roel@srv-hass-01:~/.homeassistant/custom_components/plugwise_stick$ python3 ./example.py
start connecting to stick
Exception in thread receive_timeout_deamon:
Traceback (most recent call last):
File “/usr/lib/python3.7/threading.py”, line 926, in _bootstrap_inner
self.run()
File “/usr/lib/python3.7/threading.py”, line 870, in run
self._target(*self._args, **self._kwargs)
File “/home/roel/.local/lib/python3.7/site-packages/plugwise/stick.py”, line 358, in _receive_timeout_daemon
self.expected_responses[seq_id][1].mac.decode(“ascii”),
AttributeError: ‘str’ object has no attribute ‘decode’

The home assistant log gives this output:
Apr 19 22:23:48 srv-hass-01 hass[779]: 2020-04-19 22:23:48 INFO (MainThread) [homeassistant.components.switch] Setting up switch.plugwise_stick
Apr 19 22:23:48 srv-hass-01 hass[779]: 2020-04-19 22:23:48 ERROR (MainThread) [homeassistant.components.switch] Error while setting up platform plugwise_stick
Apr 19 22:23:48 srv-hass-01 hass[779]: Traceback (most recent call last):
Apr 19 22:23:48 srv-hass-01 hass[779]: File “/home/roel/.local/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py”, line 148, in _async_setup_platform
Apr 19 22:23:48 srv-hass-01 hass[779]: task = async_create_setup_task()
Apr 19 22:23:48 srv-hass-01 hass[779]: File “/home/roel/.local/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py”, line 104, in async_create_setup_task
Apr 19 22:23:48 srv-hass-01 hass[779]: platform.setup_platform,
Apr 19 22:23:48 srv-hass-01 hass[779]: AttributeError: module ‘custom_components.plugwise_stick.switch’ has no attribute ‘setup_platform’

Any suggestions?

I removed and reinserted the usb stick and now the example.py finds the plugwise nodes. So now home assistant gives me the error:

Apr 19 22:48:59 srv-hass-01 hass[779]: 2020-04-19 22:48:59 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.plugwise_stick
Apr 19 22:48:59 srv-hass-01 hass[779]: 2020-04-19 22:48:59 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up platform plugwise_stick
Apr 19 22:48:59 srv-hass-01 hass[779]: Traceback (most recent call last):
Apr 19 22:48:59 srv-hass-01 hass[779]:   File "/home/roel/.local/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 148, in _async_setup_platform
Apr 19 22:48:59 srv-hass-01 hass[779]:     task = async_create_setup_task()
Apr 19 22:48:59 srv-hass-01 hass[779]:   File "/home/roel/.local/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 104, in async_create_setup_task
Apr 19 22:48:59 srv-hass-01 hass[779]:     platform.setup_platform,
Apr 19 22:48:59 srv-hass-01 hass[779]: AttributeError: module 'custom_components.plugwise_stick.sensor' has no attribute 'setup_platform'

No need to install the library through pip. Might even break stuff, not sure…

You only have to:

  1. remove all plugwise stick config from configuration.yaml
  2. download plugwise_stick.zip
  3. unpack it in custom_components/plugwise_stick
  4. restart HA
  5. Add plugwise stick through integrations
  6. configure
1 Like

Thanks hapklaar!

It is working now, the plugs are being discovered and show all the readings. Now I’m going to test this for a week to know it is stable before I put it in my “production” server :wink:

I had to restart the home assistant server after adding the integration. The plugs got discovered after the restart…

@Roel_van_Wanrooy good to hear!

I still have some stability issues where plugwise sensor readings suddenly just stop. home-assistant.log then shows no activity anymore for the plugwise integration. When I only restart HA I see short activity in the log @ debug, then it stops again after 10-20 lines of debug logging without obvious reasons. Only after a full reboot of the server returns to normal.

@brefra any idea what could cause this?

last lines in the logs this time were:

2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Valid message footer found at index 20
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Success acknowledge on message request with sequence id b'4CE6'
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Reset parser : b'004CE600C1CC2A\r\n# APSRequestNodeInfo: Source MAC: 000D6F000258842E# APSRequestNodeInfo: Destination MAC: \r\n000D6F0002588DB0\r\n\x05\x05\x03\x0300004CE600E1668C\r\n\x83'
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Parse data: b'004CE600C1CC2A\r\n# APSRequestNodeInfo: Source MAC: 000D6F000258842E# APSRequestNodeInfo: Destination MAC: \r\n000D6F0002588DB0\r\n\x05\x05\x03\x0300004CE600E1668C\r\n\x83' 
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Lookup message header (b'\x05\x05\x03\x03') in (b'004CE600C1CC2A\r\n# APSRequestNodeInfo: Source MAC: 000D6F000258842E# APSRequestNodeInfo: Destination MAC: \r\n000D6F0002588DB0\r\n\x05\x05\x03\x0300004CE600E1668C\r\n\x83')
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Valid message header found at index 125
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Lookup message footer (b'\r\n') in (b'\x05\x05\x03\x0300004CE600E1668C\r\n\x83')
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Valid message footer found at index 20
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Timeout acknowledge on message request with sequence id b'4CE6'
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] NodeInfoResponse request with seq id b'4CE6' processed
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Network time out received for (1 of 3) of NodeInfoRequest to 000D6F0002588DB0, resend request
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Reset parser : b'004CE600E1668C\r\n\x83'
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Parse data: b'004CE600E1668C\r\n\x83' 
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] Lookup message header (b'\x05\x05\x03\x03') in (b'004CE600E1668C\r\n\x83')
2020-04-21 00:22:40 DEBUG (Thread-2) [plugwise] No valid message header found yet
...

Are you using multiple usb devices on a raspberry pi or on one usb port on your pc? If that’s the case than it could be a power issue. I had this before because I had 2 Arduino’s, 2 FTDI sticks and a SDR radio stick on one usb port. When I connected it to a usb hub witch was powered by a separate adapter the problems were over. Some usb devices are more prone to power issues than other. My MySensors hub was having trouble all the time while the other devices worked perfectly.

The plugwise sticks are working flawlessly for a day now.

I used to, but now running everything on a NUC. Hoped that would go better. Both act the same as in they’ll eventually stop gathering Plugwise Stick data after a while and will work fine again after a full reboot.

From the log entries it looks like the processing of the timeout acknowledge message. It should resent the request but probably causes a silent crash of the send daemon. I’ll get a look into this asap.

In meantime you might try to temporarily disable this specific device.

@brefra thanks again for this wonderful component! it really made my switch from Domoticz to HA that much easier. No more need to manually add the circles to the config :smiley:
i would love to see this included in HA !

for other users which are setting this up i have a hint, which i hope will help some people before they run into strange problems, since one good thing to note is that while you can use /dev/ttyUSB0 this can lead to problems when you use multiple serial USB devices, because they’re assigned at boot and aren’t always in the same order.
if you run the following command on the HA server: ls -lah /dev/serial/by-id/
it should return something like this:

~ $ ls -lah /dev/serial/by-id/
total 0      
drwxr-xr-x    2 root     root          60 Apr 22 18:38 .
drwxr-xr-x    3 root     root          60 Apr 22 18:38 ..
crw-rw----    1 root     audio     188,   0 Apr 22 18:38 usb-FTDI_FT232R_USB_UART_A8009iRW-if00-port0

since the “Sticks” probably use the same chips it’s probable that it gives the exact same output.
you should then use /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A8009iRW-if00-port0
for setting up the integration.

if you already set it up with /dev/ttyUSB0 you can change that in the core.config_entries file

nano /root/config/.storage/core.config_entries

then press Ctrl+W (search), type plugwise and press ENTER
then replace /dev/ttyUSB0 with /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A8009iRW-if00-port0
and restart HA

@koter84 that’s interesting. If I use this way to address the stick, I can also remove and re-insert it without rebooting. Currently, the stick comes back as /dev/ttyUSB1 when I reinsert it and I need to reboot for it to be /dev/ttyUSB0 again.

By the way, my stick is listed as: usb-FTDI_FT232R_USB_UART_A5013Y63-if00-port0 so there seems to be some uniqueness to it :wink:

I will test this now

I use the serial_id too. Definitely something that should be mentioned in the documentation.

Happened again today. Seems to be a recurring issue after 2 or 3 days following a reboot. I don’t think I can disable the circle for which it seems to fail as this is the Circle+ which is essential if I’m not mistaken?

Wil try to remove then reinsert the stick next time it happens, to see if that also helps.

Thanks for the feedback. It is possible to disable all sensors & switch of the circle+ in Hass. It keeps the other devices working but won’t update the state of the circle+ anymore, which seems to causing an communication issue in your situation.
The Circle+ is only required for network linking and discovery (during Hass startup) It’s not required to allow the stick to communicate directly with the other devices when they are properly reachable throughout the zigbee network. I.e you can still switch circles without having the Circle+ plugged in. :grinning:

I’m busy to add some additional code to make library (especially the worker threads) more reliable and hopefully fixes your problem too. It will make the config flow in, and restarts of, Hass to be more reliable. Please be patient :wink:

Just wondering: Do you have a stealth device and is it working in the latest version?

Waiting patiently :wink:

Yes I do have a couple of Shields. They are however detected as circles in HA and work the same as far as I have seen. If there is anything you need me to test specifically, let me know.

Is there a way to use this great Plugwise component without a Circle+?

Mine Circle+ is death but the other Circle’s work fine with Plugwise-2-py. Is there a way to manually add the Circle’s mac addresses?

I managed to get the integration working by following @hapklaar’s instructions (thanks!) here: Plugwise Plugs component. This way you can even add it as an integration.

Great work @brefra, auto discovery is working, stealth also works as described by “hapklaar”.

I would recommend changing the installations instructions from manual (which does not work on hass.io) to the above linked.

What does not work: renaming a device (through the integration) does not update the entity names.

Thanks for the hard work!

Hi @brefra,

How are the plans now, do you think you can get it to a native integration? Or release it for HACS?

I’m really looking forward to it. Or will it take more time and should I install it as a custom component?

Thanks, looks good!!