Thank you very much for the guide.
I’ve just finished re-re-re-configuring the cube before my wife gets home (close one this time!). I’ll do this tomorrow and hope fully it will work. It’s also good to know that we can keep the old functionality of wall thermostat + radiator pairs since i got a couple of them…
I’ll update tomorrow with the (hopefully) good news…
One question though… what’s the downside of no-credits firmware? More battery usage probably… Anything else?
Yes - I guess battery life is probably impacted a little, but probably negligible since the thermostats only send when they need to anyway (ie. when the valve position changes).
Also if you have LOTS of RF devices, I guess your airwaves could be busier and temporarily block signals, but again probably not an issue for most people.
I’m using Homegear (in Docker on HassOS), but with a Cube für MAX! and a nanoCUL for HomeMatic. For the nanoCUL I’m using a responseDelay of 95. By the way, the adress of my USB nanoCUL is /dev/ttyUSB0 and not /dev/ttyACM0. Maybe, you should check this.
Cool, looks promising 
I can see that in config.json the devices are hardwired. I think there is the possibility to detect the devices automatically via the auto_uart config to integrate them into Docker. So you wouldn’t be limited to the two variants.
You can use somehting like this https://gist.github.com/vladbabii/cc1bbcd6b61485caefece5f04370eb7e to set it it to a fixed /dev/something location. Just list your usb devices and find the correct vendor id and device id and replace them. Also if you set SYMLINK+=“cul” then the device will be /dev/cul .
The RUN+="/bin/x-hass-restart-zwave-replug" can be removed or can be set to a script that does something is the usb hickups or you remove/replace the script (for zwave i restart the home assistant after 10 seconds, for other sticks / adapter i use service restart and so on…) This was added because usb can hickup and remove/re-add the usb connections randomly without physically removing them…
Success! I have thermostat+ 1 to 3 radiators in various rooms. When i change a thermostat the radiators get updated instantly!
And you don’t actually need the homematic binding, just use mqtt!
You can edit /etc/homegear/mqtt.conf and set your broker, then, in home assistant add to the climate component at least the thermostats (in my case changing thermostat values also triggers the radiators)
# modes:
# 0 - auto
# 1 - manual
# 2 - party
# 3 - boost
- platform: mqtt
name: Office Thermostat
retain: false
send_it_off: true
current_temperature_topic: service/homegear/8347/plain/1/1/ACTUAL_TEMPERATURE
temperature_state_topic: service/homegear/8347/plain/1/1/SET_TEMPERATURE
temperature_command_topic: service/homegear/8347/set/1/1/SET_TEMPERATURE
min_temp: 10
max_temp: 30
temp_step: 0.5
modes: ["auto","manual","party","boost"]
mode_state_topic: service/homegear/8347/plain/1/1/CONTROL_MODE
mode_state_template: >-
{% set values = { '0':'auto', '1':'manual', '3':'boost'} %}
{{ values[value] if value in values.keys() else 'off' }}
I don’t use party mode so i hide it…
Works very well. Also I disabled node-blue since it was causing very high cpu usage on idle in homegear.
Now I only need to make mode_command_template to work with
# mode_command_topic: service/homegear/8347/set/3/1/CONTROL_MODE
# mode_command_template: >-
# {% set values = { 'auto':'0', 'manual':'1', 'boost':'3'} %}
# {{ values[value] if value in values.keys() else '0' }}
details in this thread - Need help with value_template for MQTT HVAC
Mqtt binary sensor template for battery level
- platform: mqtt
unique_id: heating_battlow_office_thermostat
name: Office Thermostat Low Battery
state_topic: service/homegear/8347/plain/1/0/LOWBAT
payload_on: true
payload_off: false
device_class: battery
What is the advantage of using MQTT instead of the Homematic Binding when connecting Homegear to HomeAssistant?
One less binding to worry about/upgrade/test… decoupling components since mqtt is an easy standard… I can update only parts of the home automation system… For example, I had a (old version of) home assistant + cube plugin in a container that handled heating and pushed everything to mqtt, now i replaced that container with a home gear one… When something breaks or needs upgrade it’s usually a “slave” that needs working on so I can turn off a part of the home automation and everything else works… And if something breaks i can just turn off a part of the system, not everything…
I run everything in my home on mqtt, so it’s easier for me…
Thanks for the feedback, I’d heard of MQTT support in homegear, but not investigated it at all.
Might switch my setup to this, since I’m using MQTT for most other things - as you say, one less thing to test at update time
I’m interested to know if anyone found a good (efficient) way to send automatic schedules to the thermostats via homegear?
I’d like some ‘day temperatures’ for some of my thermostats for rooms that are unoccupied during the day, but also to revert to the previous manual temperature at night.
One way I thought of was to store the manual temperature in a number entity then use that to revert back at night… but it feels messy…
I wondered if I could make use of the auto mode during the day and then switch to manual mode at night - but I’ve not yet tested if the previous manual temperature is remembered when you switch from auto…
If you use MAX! Thermostats, I would recommend to use HomeMatic Manager so store the time tables of temperatures directly on the thermostats, as this is way more robust than using Homegear / HomeAssistant for those schedules.
Indeed, thats what I was thinking, but it seems setting these values for each thermostat is very clunky in homematic manager (unless i’ve missed something).
After issuing many commands via alexa / web interface / physical devices, i got this in the homegear logs
... Module MAX: CUNX "Max-CUNX": Warning: Too short packet received: ...
When you get a lot of these messages, the integration will stop working. I restarted homegear to fix everything…
I will monitor things for the next couple of days to see if it happens again…
Does that message end with ‘LOVF’ ? - If so, you have run out of airtime credits.
(Though that shouldn’t happen if you use the no credits firmware)
I haven’t spotted that issue before, but I haven’t inspected the logs recently since everything seems to be working.
No, I’m afraid it’s really time-consuming. But it is possible to apply a configuration directly to several thermostats or to copy a configuration to another thermostat and then only adjust it.
I know that error. With me, however, it goes away after some time (a few hours?) also again by itself - without restart.
I’m using the no-credits firmware…
Interesting, is your log entry ending ‘LOVF’ ? - If it isn’t, then i don’t think that is the credits problem…
If it is, you shouldn’t be seeing it with that firmware 
Thanks for you comment. I will think about this and some other improvements like builds for other systems than RaspberryPi. I will have a look on theas features and update the Package.