Yeah that one is weird.
Any progress on your work on deacon in docker? Im reinstalling my main server and will probably move all home automation in to it as well, and then docker will be the preferred way of installation.
1 Like
I am making some progress - I have a hunch that the reason why the hardware doesn’t show up at first in the container is because deCONZ is trying to auto detect the attached hardware (ie Conbee or RaspBee) via the info generated for these devices by udev. But, udev doesn’t run inside the container and passing through a device via the device parameter doesn’t make this data available in the container - this needs to be mounted separately. But I haven’t had a chance yet to test this hypothesis and haven’t gotten a reply from @manup yet to confirm/deny my theory.
1 Like
Have you read this blogpost? https://www.guidodiepen.nl/2016/05/notification-of-new-usb-devices-in-docker-container/
1 Like
I’d not seen that, thanks. But the problem here is slightly different. Udev enumerates a lot of data about connected USB devices (just check the output of udevadm info -a -n /dev/ttyUSB0) that doesn’t get passed through to the container (see e.g. https://stackoverflow.com/questions/41753218/udevadm-does-not-show-all-attributes-inside-a-docker-container). So if deconz is trying to detect based on attributes, that may be where it’s falling down.
1 Like
Well you seem to know a lot more than me about this. I just googled around and thought that it might be relevant information.
Would you mind review the component documentation tomorrow when you play around with deconz a bit more?
1 Like
Sure thing - I have some updates to make to the compatibility list as well.
2 Likes
This sensor (motion sensor) does report battery (ie it has the feature, I have seen it in Xiaomi Gateway), but log says
‘_battery’: None
Also, on reboot of PI it is in state “Unreachable” until motion is detected, but other than that I find it (pydeconz component) very stable.
I never got the switch to show up in UI (but I interpret your answer that they shouldn’t? Not even on the “/dev-state”-page in HA?). I can see it being created in the debug logs, and pressing button also shows up in log. But no switch on the /dev-state page in HA (and nothing in Phoscon app). Haven’t had time to test trigger events on it yet, but will look in to it this weekend. Probably works fine.
Here are the logs:
2017-12-13 06:08:59 DEBUG (MainThread) [pydeconz.deconzdevice] Motion Sensor created as {‘_reachable’: False, ‘_sensor_class’: None, ‘_on’: True, ‘_sensor_icon’: None, ‘_uniqueid’: ‘00:15:8d:00:01:e0:30:03-01-0400’, ‘_n
ame’: ‘Motion Sensor’, ‘_swversion’: None, ‘_async_callback’: , ‘_ep’: 1, ‘_battery’: None, ‘_manufacturername’: ‘LUMI’, ‘_modelid’: ‘lumi.sensor_motion.aq2’, ‘_type’: ‘ZHALightLevel’, ‘_sensor_unit’: None, ‘_etag’: ’
bdbb2a083301b263d957b1590204846d’, ‘_lightlevel’: 0}
2017-12-13 06:08:59 DEBUG (MainThread) [pydeconz.deconzdevice] Motion Sensor created as {‘_reachable’: False, ‘_sensor_class’: None, ‘_on’: True, ‘_sensor_icon’: None, ‘_modelid’: ‘lumi.sensor_motion.aq2’, ‘_presence’:
False, ‘_name’: ‘Motion Sensor’, ‘_swversion’: None, ‘_async_callback’: , ‘_uniqueid’: ‘00:15:8d:00:01:e0:30:03-01-0406’, ‘_ep’: 1, ‘_battery’: None, ‘_manufacturername’: ‘LUMI’, ‘_sensor_unit’: None, ‘_dark’: None, ’
_etag’: ‘bdbb2a083301b263d957b1590204846d’, ‘_type’: ‘ZHAPresence’}
2017-12-13 06:08:59 DEBUG (MainThread) [pydeconz.deconzdevice] lumi.sensor_switch created as {‘_reachable’: False, ‘_sensor_class’: None, ‘_on’: True, ‘_sensor_icon’: None, ‘_uniqueid’: ‘00:15:8d:00:01:b1:86:3d-01-0006’
, ‘_name’: ‘lumi.sensor_switch’, ‘_swversion’: None, ‘_async_callback’: , ‘_ep’: 1, ‘_battery’: None, ‘_buttonevent’: 1002, ‘_manufacturername’: ‘LUMI’, ‘_modelid’: ‘lumi.sensor_switch’, ‘_sensor_unit’: None, ‘_etag’:
‘bdbb2a083301b263d957b1590204846d’, ‘_type’: ‘ZHASwitch’}
Button press:
2017-12-13 06:29:09 DEBUG (MainThread) [pydeconz.websocket] Websocket data: b’\x81s{“e”:“changed”,“id”:“3”,“r”:“sensors”,“state”:{“buttonevent”:1002,“lastupdated”:“2017-12-13T05:29:09”},“t”:“event”}’
2017-12-13 06:29:09 DEBUG (MainThread) [pydeconz.deconzdevice] Update {‘lastupdated’: ‘2017-12-13T05:29:09’, ‘buttonevent’: 1002}
2017-12-13 06:29:09 DEBUG (MainThread) [pydeconz.deconzdevice] Update {}
2017-12-13 06:29:09 INFO (MainThread) [homeassistant.core] Bus:Handling <Event deconz_event[R]: event=1002, id=lumisensor_switch>
1 Like
Maybe it doesn’t have a battery value supported in deconz? Check the debug prints what value the battery has on initialisation of component.
Unreachable is a zigbee state, it is just expressed by the component.
Correct. Switches are momentary events only, no need for an entity representation. The only representation of the switch in the gui is the battery entity and its attribute which tells you the name of the event.
1 Like
@Robban, I have some edits to make to the docs and I will make it clear that no entity is created for remotes/switches, only a battery entity.
1 Like
I can do the edits if you post your comments
OK I’ll take a look and send some edits today!
Last comment in PR as I guess you already seen: “Due to lack of support in deconz, battery values are still not reported.”
It is unreachable in Phoscon aswell, so correct in component. But still misleading I think. By UI means.
Made a simple test, which works fine.
- alias: Button
trigger:
- platform: event
event_type: deconz_event
event_data:
id: 'lumisensor_switch'
event: 1002
action:
- data:
message: "Button pressed"
service: notify.ios_mattias_iphoneToo bad HA doesn’t present a list of available devices though. Would have been a nice feature.
Hit a snag in testing today - my hue motion sensor wouldn’t join, but that’s a deconz issue that will be fixed in version .98 tomorrow. So I wasted a lot of time on that and didn’t get to doing what I wanted to do about the component - I’ll get to it tomorrow instead.
I finally got a chance to play with this again and after version .99 of deconz pair my Hue Motion Sensor.
After a restart of HA the binary sensor, temp sensor, and light level sensor are all pulled into HA, perfect. One comment I have is that the light level and temperature sensors should have their Name/entity id reflect their function, so three entities should be created like:
binary_sensor.sensor_name_from_deconz
sensor.sensor_name_from_deconz_temperature
sensor.sensor_name_from_deconz_light_level
With the code as it currently stands I have two sensors, one named sensor.living_room_motion_sensor and sensor.living_room_motion_sensor_2. I can set a friendly name in customize but I can’t change the entity ids, so it might be better to have those ids intuitively follow their function - I think this is how the Wink component, for example, does it more or less.
The alternative to me forcing naming them which would include all devices even though they might just be a temperature sensor. Try rename it through the hass service. If that doesn’t work I might be required to so a suffix.
Can’t rename entities as far as I know - you can give them a friendly name but that doesn’t change the entity id. I think it would be preferable to have sensor entities suffixed with their function (_motion, _temperature, _light_level, etc). I think that’s the way other components like Wink do it when they break out the individual attributes as sensors.
I meant that you could use the deConz service in HASS to rename the different sensors real names in deconz. That would affect the entity id of the sensor
I will try that and let you know how it goes. Also, the battery sensors that are created for remotes/switches have “battery level” appended to them in lowercase; I think it would be preferable to have “Battery Level” starting with uppercase letters.
I’ll look into the naming of battery level
Followed your suggestion and changed it to Battery Level