Thanks! I’m sure the picky people like me will appreciate it
I’ve had this error starting to come up just today, I’m not sure if it’s related to deconz as I haven’t dug into the debug logs yet, but deconz is the only thing running on my test instance:
Error doing job: Fatal read error on socket transport
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/selector_events.py", line 723, in _read_ready
data = self._sock.recv(self.max_size)
OSError: [Errno 113] No route to host
As I said I’m not sure if it’s deconz but I will check tonight and see. I will also try to check over the docs and let you know what I think
Here are a few documentation items I would add (my addition in bold):
To deconz.markdown:
Remote controls or switches (ZHASwitch category) will not be exposed as a regular entity viewable on the “States” ( < > ) page of the frontend, but as events named ‘deconz_event’ with a payload of ‘id’ and ‘event’. Id will be the device name from deCONZ and Event will be the momentary state of the switch. An extra entity battery sensor will be created to show battery levels of switch. [Remove the previous sentence and add:]However, a sensor entity will be created that shows the battery level of the switch as reported by deCONZ, named sensor.device_name_from_deCONZ_battery_level.
To light.deconz.markdown:
Entity Ids names will be light.device_name, where device_name is defined in deCONZ. Light groups created in deCONZ will be created in Home Assistant as lights named light.group_name_in_deconz, allowing the user to control groups of lights with only a single API call to deCONZ.
Supported devices to add to light.deconz.markdown:
Philips Hue White A19
Philips Hue White Ambiance A19
With respect to sensor.deconz.markdown, I would remove all switches from the list of Verified to be supported sensors. Switches don’t follow the same entity convention as sensors (with the entity id, etc) and will confuse users (this was one of the reasons I wondered why there wasn’t an entity created for my Hue Dimmer and Tradfri remote). Switches are already covered in a section on the main deCONZ component page, so maybe you could move the list of supported switches to there instead.
Regarding the error - I lost my debug logs when I stopped, rebased, and restarted my test environment so I’m going to have to wait to see if it happens again before I have more information on it.
Just substitute marthoc/home-assistant-deconz for the normal image name in your docker run command. If on a raspberry pi, add the :rpi tag: marthoc/home-assistant-deconz:rpi.
Seems to be working very well in my testing and seriously simplifies my docker-compose workflow haha.
Now to just figure out this pesky issue with deconz in docker and we will be all set…
Couldn’t you host an initial docker image? Maybe all functions aren’t complete, but the configuration part would be. I’d be glad to try out deconz in docker. Regardless of firmware upgrade, that would come later on. That would mean I could start migrating to my new server.
I’d suggest trying @abmantis image that he previously shared on the DE GitHub: https://gist.github.com/abmantis/09df711ece2e9f5b5156fea193a05862 . It works as well as my own design, which is to say, only inconsistently and I often can’t get my hardware recognized by it. Just change the deconz version to 2.04.99 before building.
i’ve hue v2 and has some issues with wifi and zigbee inteferences but chanced zigbe channel and no i am running both. Will add another smart light and test how it works. did not test with xiaomi yet
Deconz software is the base of the implementation right now. It is one half of the brain with hass on the other side with the component being synapses between the halves
Do you mean the Hue Dimmer or is there a specific remote for that light? I’ve been using a Hue Dimmer, it works well. For other items I agree with @Robban, raise an issue. The devs there are pretty responsive.
there is another remote… i opened issue… now i have this issue:
2017-12-21 01:03:26 ERROR (MainThread) [homeassistant.components.light] Error while setting up platform hue
Traceback (most recent call last):
File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/helpers/entity_component.py", line 171, in _async_setup_platform
SLOW_SETUP_MAX_WAIT, loop=self.hass.loop)
File "/usr/lib/python3.4/asyncio/tasks.py", line 372, in wait_for
return fut.result()
File "/usr/lib/python3.4/asyncio/futures.py", line 277, in result
raise self._exception
File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
result = self.fn(*self.args, **self.kwargs)
File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/light/hue.py", line 110, in setup_platform
unthrottled_update_lights(hass, bridge, add_devices)
File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/light/hue.py", line 149, in unthrottled_update_lights
lambda **kw: update_lights(hass, bridge, add_devices, **kw))
File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/light/hue.py", line 190, in process_lights
lights[light_id].schedule_update_ha_state()
File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/helpers/entity.py", line 273, in schedule_update_ha_state
self.hass.add_job(self.async_update_ha_state(force_refresh))
AttributeError: 'NoneType' object has no attribute 'add_job'
