ConBee ZigBee Stick and HA, will this work together?

Had a talk with balloob. Moving switches over to events. The pr is updated. Haven’t solved how I will do with the battery yet

Great there were a consensus about that, i am sorry i did not have time to sit down and reply thoroughly what i meant with the events.

You can ask him about battery and i hope that he agrees there should be a special sensor with battery level for each supported switch.

Since the sensor will be an event the battery will be it’s own sensor. I’ve just not decided how to do it :slight_smile:

I have one solution for battery sensor ready to be tested.

I’ve posted documentation about the component. I don’t feel that it is in any way good yet. I’d like some feedback to make the documentation useful for new users.

Just want to let you know I’m also currently testing your component and its working fine as far as I can tell after one hour. :wink:

Will go more into details and start to trigger some automations from remote presses/motion detection as next steps.

What I was struggling most with is to get my devices connected to deconz just using the webapp. I managed to get some IKEA bulbs, switches and a motion sensor connected. But no success with a HUE motion sensor so far. Any hint for me?

Just asking: Whats the state of the other components linked in this thread?
Are there multiple “competing” ones to try or is Robbans the way to go at the moment?

Keep up the great work!

1 Like

@dkmh i think the most wise thing is to go with @Robban’s component since he is implementing all that i have in my component and most likely also more :wink:

Regarding your HUE motion sensor, take battery out, do a full reset of the hue motion sensor, open deconz network, put the battery in and wait for it to show up in deconz.

1 Like

I am currently hit by a HASS but so i can’t get my test instance up and running, i’ll get back with feedback when i got it working.

@Robban I finally got my test instance working so here is some feedback :

  1. Temperature should be divided by 100 at least for Celsius.
  2. I strongly suggest that you use lux value from ZHALightLevel sensors or calculate it yourself from lightlevel as i do here : state=round(10 ** (float(v[‘state’][‘lightlevel’] - 1) / 10000),1)
  3. Please add following for battery sensors :
unit_of_measurement: %
icon: mdi:battery
  1. Please add following on temperature sensors (at least for Celsius):
unit_of_measurement: °C
device_class: temperature
  1. Please remove battery from the entity name on battery sensors or is it really important to have that info ?
  2. Regarding the events, i can’t try it at the moment since i am not home but i had a look at this line https://github.com/Kane610/home-assistant/blob/abdb0e26432e63668e583d9f62ef1f53f26ac893/homeassistant/components/sensor/deconz.py#L98 and as far as i can see you put into the event the nodestate from the sensor which usually involves buttonevent for ZHASwitch and lastupdated which means that an automation like this :
- alias: "Trigger Kontor light"
  initial_state: true
  trigger:
    platform: event
    event_type: dcz_event
    event_data:
      id: Kontor
      button: 1002
  action:
    - service: light.toggle
      entity_id: group.kontor_light

Would be much more complicated to do afaik because i cant’t get the value of button but have to parse the json message. If it can indeed be done in HASS which i believe it can then it won’t be pretty so i would suggest the events are specific for buttons where you send an event with buttonevent number instead the full state. You can of course also make a field for lastupdated since some may find it usefull (i don’t use it). You then need to have at least two type of events one for ZHASwitch and one for ZHAPresence. Hope you agree.
6. I have not tested lights enough but will get back when i have same goes for physically switches.

1 Like

Great feedback! Will take a look at the details tomorrow evening since I’m away on a workshop atm.

Regarding the event, I’m sending it in the same way as you. State is a wrapper for buttonevent so you will only get the button press in the event. This is to standardize and let all sensors report their unique main state in the same way.

I think it is reasonable to aim for release 59 of Hass if we try to get it out of WIP status this week

Great !

Yes then i am ok, as i said i haven’t tried it in real life.

What about the ZHAPresence ? Does that also send events ? I would suggest to do so. Actually with the Motion sensor i suggest both a sensor and send events. The reason i think the motion sensor should also be created as a sensor is that it’s really nice to see history of a motion sensor e.g when was there motion in case of a alarm or something else and also for the visibility like is there motion rights now ? As for the automation user can choose between using events (should be recommended) or use the state of the sensor.

The same goes for ZHAOpenClose, this should also be both sensor and event, user can choose which one to use for his automation.

I have not started to move over to the new component so it’s still in test environment for me. I need to do some minor changes to my automations if i move over for instance the event name which is not the same.

hello,

I read that you are using the ConBee usb stick, the same configuration works with RaspBee hardware?

I’m searching a store online to ship to Italy, and is more easy to buy a RaspBee than a ConBee.

Thanks.

It is actually configurable but not documented :slight_smile:. Check the config validation in the component

Yes it does

Yes so what you are saying is that in the config you can configure which type should send events here : https://github.com/Kane610/home-assistant/blob/abdb0e26432e63668e583d9f62ef1f53f26ac893/homeassistant/components/deconz.py#L35 but it does’t change the fact that if i choose that for a ZHAPresence then no sensor is being created right ? I mean it’s either or but not both ? I still think it’s really beneficial to have both for some type of sensors such as ZHAPresence, ZHAOpenClose where history is really good to have at the same time as events.

For presence detector and buttons; Isn’t this just as easy as an event? It’s even one line less than your example. So I can’t see that you’d need the presence detectors as events.

automation:
  - alias: step_up
    trigger:
      platform: state
      entity_id: sensor.1
      to: '2002'
    action:
      service: input_number.increment
      entity_id: input_number.slider1
  1. How do I know if temperature is reported through Fahrenheit or celsius?
  2. Is the lux parameter available in state{} on all light level sensors?
  3. Will do!
  4. As soon as I know #1
    4-2. I think it is good to explain that it is a battery sensor, you can always use customize, how does other components do this?
  5. All json parameters are exposed as their own parameter in the device, that includes config and state, so every single value is available separately, so no need to parse json structures inside automations. So I hope you agree that there is no reason for events for ZHAPresence or ZHAOpenClose.
    6 I’ll await your feedback.

Could you possibly give me full json device structures for temperature sensor and light sensor when you do a get sensors from deconz?

Yes i guess you are right at least in this example. I have no idea if events are better in the sense that an automation just looks at events instead of looking at a entity state which is updated from an deConz websocket event. The events seem one step less in my head. I guess i could get along with the sensor but at the same time it’s a one liner. I don’t know enough about the inner working in HASS, i guess only ballobb knows if both are ok or you have to settle on one way to do it. For my personal preference i would go with both but you decide.

I’d like to keep it simple, at least initially, there will be enough to review for the hass guys anyway. If you don’t like it after a few weeks we can talk about it again :slight_smile:

Btw are you danish or something? I get the feeling you’re danish :smile: