So here’s the deal: I have routines that restarts everything if something happens, based on Node-RED as the “fallback”. If the Pi with Hass and Z-Stick loose the connection with MQTT, Node-RED does a “nice” reboot of that, by stopping Hass first. Hass starts on startup. But if the MQTT broker is not online when Hass starts, any automations with MQTT in the trigger will be deactivated on startup and can’t even be reactivated manually! It happened during the night, while the Z-Wave switch controlled wall heater was on. Hass should have turned it off on 18 degrees, but didn’t. This is bad. Very bad. 30 degrees in one of the bedrooms this morning bad! So is there a way to avoid this, or is this part of the design?
I don’t trust HA enough to let it control room climates. I set the heater’s own thermostat to the temp I want and just control when it is on or off with HA.
So you’re saying that the automation turns off from the frontend and cannot be turned on? Sounds weird so thinking that I understood it wrong.
But you should still be able to trigger the automations manually. Have you tried that and does the system respond correctly?
Do you use retained messages in mqtt? This means that if a message has the retain flag the broker will resend this message when topic is subscribed.
Considering: no retain, broker online, HA offline.
- Message to topic by some device
- HA online and subscribes to same topic
- HA will not see the message published earlier. (Unless it would have been sent with retain)
I agree with the previous poster. I woudnt either trust HA (specially running on raspi) to directly control heating. Only to adjust setpoint.
Hopefully you get some ideas out of this 
Happy to storm more!
For me that makes the whole smarthouse thing totally useless. Except for this problem (and one other problem about 6 years ago which was easily fixed) I have been running the heat in one cabin and two consecutive houses the same way for 8 years - with thermostats set to 30 (since fast heating of a room means that the air close to the heater will get hotter than necessary) and temp sensors keeping the deviation within one degree, with fully automated night, day and frost guard temps.
1 Like
I never really use the frontend, I just went into that to see what was happening. I’m running a fully automated system controlled by webpages that are ran from a virtual machine on my main server, so in the central system, not in Hass or other Pi based systems. And the math and control is happening in the main virtual machine, the Pis are basically dumb clients that are told to turn on and off stuff with MQTT messages, and sends the input from switches and temperature sensors to the main virtual machine.
All automations that has an MQTT trigger (not the ones that has an MQTT action) are turned off/deactivated if Hass starts when the MQTT broker is not available to it. And these automations can’t be triggered manually because they are dependant on the payload that’s sendt by the MQTT message. What they can be is turned on and off manually by switches in the GUI (or activated and deactivatede, if that makes it more clear), and when this startup without MQTT available has happened, they are turned off and can not be turned on before Hass is restarted with an available MQTT broker.
I have managed to get it under control by moving the Pi to another room nearby with a wired network connection. It turned out that the problem was somewhere in the wireless network. But still if this can be replicated by anybody else, it is a bad flaw. At the end of this post I have one of the simpler automations if anybody wants to test.
As for retain, no. There are around 70 messages every minute from the temperature sensors alone (with two RFXtrx and two Tellstick Duo placed in strategic locations around the house, the house is a bit difficult because of a big chimney and some hobbit fireplaces, and tiles on the bathrooms that eats 433 mHz signals. So that would mean an untold number of messages when the Pi connected. Also I have all in all four Pis (only one with Hass, the rest with Node-RED), so if they all went out and came back one after one (power failure or similar - my server has an 8 hour UPS system) it would probably be too much for the broker.
The 1-2-3 isn’t really necessary, because the central system sends a signal every five minutes to MQTT (not every minute, when the sensors come in, to avoid too much signal traffic), and nothing bad happens with heat in five minutes. So if Hass had started up everything as it should, it wouldn’t have been a problem at all. Oh, and all problems in the system triggers a mail to me, so I know what’s happening, and stuff can’t be out for more than my 8 hours of sleep no matter what.
As for controlling setpoint that’s just too inaccurate, especially in larger rooms with one or two big glass panel heaters. There I have two temp sensors and a script that syncs them to keep an even heat in the room. Again, I have several years of similar systems, and the glitch I found in Hass here could always be contained in some way. If the wired network hadn’t fixed it I would probably have set up a local broker on the Pi with forwarding to the broker on the server.
Here’s one of my automations with MQTT as the trigger. I have translated it from Norwegian to English, so if there’s an error there, that’s from the translation. 
The MQTT message that triggers them is either ZWaveSwitchHeaterOff or ZWaveSwitchHeaterOn, with the zone (room) number as the payload, so the switches have names like switch.zwaveswitch_heater_15 or switch.zwaveswitch_heater_2
#Heaters on/off
- alias: Heater - off
action:
data_template:
entity_id: switch.zwaveswitch_heater_{{trigger.payload}}
service: homeassistant.turn_off
condition: []
id: '152466356'
trigger:
platform: mqtt
topic: ZWaveSwitchHeaterOff
- alias: Heater - on
action:
data_template:
entity_id: switch.zwaveswitch_heater_{{trigger.payload}}
service: homeassistant.turn_on
condition: []
id: '15246136'
trigger:
platform: mqtt
topic: ZWaveSwitchHeaterOnNow I start to catch your problem. So HA turns those mqtt trigger automations off by itself if the broker happens to be offline on start?
And turning the automation on doesn’t do “anything” as it then needs the trigger. And I believe that the automations does not trigger unless the topic actually changes. I mean it triggers only once even if you bomb it payload “15”.
Go around it for now by running an automation at startup that turns all automations on?
Yes, they are turned off/deactivated if the broker is offline at start of Hass. And I can’t get around it for now beacuse it seems like it’s not possible to turn them on in any other way than by restarting Hass when the broker is online again. I believe the error was something like “service MQTT not found”.
The only way to do that would be to build in a startup script in Hass that restarts Hass if there is no connection to the MQTT broker, but that’s far beyond my abilities.
And I believe you’re wrong about the triggering, from what I can see it triggers every time I send ZWaveSwitchHeaterOff with the payload 15 from the central system and send off to the Z-Wave switch. But I may be wrong about that, it’s a while since I made these (they had been running on a Pi that was connected to a wired network - that may be the reason I never saw this before, or it may be because I was using an earlier build of Hass). The main thing is that it triggers when there is a change (going from on to off and off to on), and that happens every time.
I guess it’s the service that doesn’t start at all when there’s no connection. This is from startup:
Log Details (ERROR)
Sun Nov 04 2018 20:04:07 GMT+0100
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
result = coro.send(None)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/automation/__init__.py", line 255, in async_enable_automation
await self.async_enable()
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/automation/__init__.py", line 305, in async_enable
self.async_trigger)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/automation/__init__.py", line 411, in _async_process_trigger
remove = await platform.async_trigger(hass, conf, action)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/automation/mqtt.py", line 53, in async_trigger
hass, topic, mqtt_automation_listener)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/mqtt/__init__.py", line 280, in async_subscribe
topic, msg_callback, qos, encoding)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/mqtt/__init__.py", line 662, in async_subscribe
await self._async_perform_subscription(topic, qos)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/mqtt/__init__.py", line 697, in _async_perform_subscription
_raise_on_error(result)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/mqtt/__init__.py", line 782, in _raise_on_error
'Error talking to MQTT: {}'.format(mqtt.error_string(result_code)))
homeassistant.exceptions.HomeAssistantError: Error talking to MQTT: The client is not currently connected.Do you ensure the broker (Mosquitto?) service starts before Home Assistant?
After=network.target mosquitto.service
First of all, thanks for trying to help! But I see that I wasn’t accurate enough. As I said I have several Pi’s that connect to the same broker. This is a central broker running on the main server (so no local service), and Hass is the only thing that has a problem with network glitches at startup. If the broker isn’t available (it’s always up, but sometimes the Pi doesn’t log on to the wifi before Hass is started, even if I have After on network start), I consider it a bug that Hass just errors out and doesn’t ever try to connect again. My other componetns (EventGhost, Node-RED) will keep trying until the broker is accessible. Hass never tries again if the broker isn’t accessible at startup.
Log an issue on github.
Why not make an automation that turns the automations on after the broker spools up. Yes it will be a band-aide to mask the real problem, but it should get you up and running through restarts.
Tom_I, I have.
Petro, no help. As I write in the first and third post the only way to get them working again is to restart Hass fully, so it has contact with the MQTT broker at once. Turning them on manually doesn’t work, and then I think it would be rather safe to assume that using an automation for the same thing won’t help either.