Ok I think I got it.
Question, currently I am using deCONZ on a separate pi3: now, if I install, on the same pi3, HASS under docker (I wish ot test the zha/zigbee component) will it work (concurrently deCONZ and HASS/Zigbee)?
Tried but failed, putting /dev/ttyUSB0 (tried also 1, 2, 3, 4)
lsusb
Bus 001 Device 004: ID 0403:6015 Future Technology Devices International, Ltd Br idge(I2C/SPI/UART/FIFO)
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubAs far as i can tell (Note: I just learned today that there is a deconz hardware driver for the Home Assistant implementation, and never tested it) both deconz and zha will never work at the same time, as both applications require a serial connection to the hardware stick which cannot be shared beween 2 running applications.
That aside, switching between both applications isn’t ideal either as a lot of information about the network, the devices and bindings is stored in within the applications.
It is ready(ish)
Clone it and try it out lets see if it works at all
Wow that was quick, thank you for looking into it so quickly 
I’ll try my best to help you test / debug it.
What i’ve tried:
- checked out the branch from your github fork
- replaced (lazy i know) my local installation with the branches content
- installed pydeconz 48
- started hass
unfortuatly no new component visible.
So I’ve changed the logger to debug and ran hass again, i could see pydeconz parsing the sensor data and adding a sensor named “902010/32”…
Ok, maybe it’s the name of the sensor thats casing trouble. Renamed it to ‘foo’ and ran again:
DEBUG (MainThread) [pydeconz.deconzdevice] foo created as
{‘_async_callbacks’: ,
‘_async_set_state_callback’: <bound method DeconzSession.async_put_state of <pydeconz.DeconzSession object at 0x68ed6470>>,
‘_battery’: None,
‘_deconz_id’: ‘/sensors/52’,
‘_ep’: 1,
‘_etag’: ‘828fe6c274c5b7e74536ba3e8d9d7cc8’,
‘_heatsetpoint’: 2200,
‘_lowbattery’: None,
‘_manufacturername’: ‘Bitron Home’,
‘_modelid’: ‘902010/32’,
‘_name’: ‘foo’,
‘_offset’: 0,
‘_on’: True,
‘_reachable’: True,
‘_scheduler’: None,
‘_scheduleron’: False,
‘_sensor_class’: None,
‘_sensor_icon’: None,
‘_sensor_unit’: None,
‘_swversion’: ‘V1b225-20151013’,
‘_tampered’: None,
‘_temperature’: 2290,
‘_type’: ‘ZHAThermostat’,
‘_uniqueid’: ‘00:0d:6f:00:04:24:72:4f-01-0201’}
Again, not visible in the frontend 
Also, I get no climate related log entries, I would have expected to see something like:
[homeassistant.components.cover] Setting up cover.deconz
I suspect its maybe my setup, did I miss something?
Did you do this an hour ago? I missed to add the climate platform to the list of supported platforms. Could be that easy. Updating the init.py and const.py files with the latest on branch should solve it
It was that easy 
I’ll play with it and keep you update
1 Like
If it works we might get it into todays beta 
Do you know the difference between config on and state on?
At first glance a few observations:
a) I hacked climate.py line 93 to:
data[‘heatsetpoint’] = int(kwargs[ATTR_TEMPERATURE] * 100)
To get the expected value like 2300 for 23.00°c
b) The on/off toggle switch gets populated in the deconz rest API, but is ignored by the device. I might look into that as I am more comfortable in C than python.
c) Setting a new target temperature in HA is almost instantly transfered to the device.
d) Setting a new target temperature at the device take either a very long time or is not updated in the API
Overall, looks good 
just the setpoint needs to be adjusted.
And on deconz side the transfer of the state needs to be investigated.
My expectation would be:
state.on: physical state of the relay
config.on: software switch if the thermostat should control the heating
So compared to how lights are doing it (/state) I’m using /config for thermostat, maybe on should be state?
I’ve fixed the conversion for heatsetpoint, going to quick some times…
Update config.heatsetpoint when it is changed manually on the device
Might be a bug you have then?
I have a couple of Climax Power and metering switches. Latest firmware on the ConBee,
deCONZ_Rpi_0x26300500.bin.GCF.
Getting zero metering values into HA. Any ideas what’s wrong?
Dresden think it should work.
Overall the reporting is not very reliable. I’ve seen gaps in the reported temperature for more than 10 hours 
I’ll have a look at the pull request and patch my rest interface hopefully this weekend.
@Tomahawk just FYI: Dresden is a city and the Company is just named after the city its located in.
He he. I thought all you HA people were magicians
Do i have to do this, or do i look in the Decoz log?
https://developers.home-assistant.io/docs/en/hassio_debugging.html
You can get the logs by going to the about screen. But you need to enable debug per instructions on deconz components documentation
Did set the deConz parameters like this:
"debug_info": 1,
"debug_aps": 1,
"debug_zcl": 1,
"debug_zdp": 1,
"debug_otau": 1,
This is my Climax power socket and power meter switch in HA. In Phoscon the switch comes up as a light(?), but named as switch in HA.
Here are two logs, one right after restart of HA.
The other some minutes after restart.
Please do you magic : )
No no, the component documentation. We need to look in the Rest API logs