Hello Community,
after the core update to 2023.6 I already noticed problems with MQTT. Now I found that after the update to 2023.7 the problems are the same. At the moment I am back on 2023.4 thanks to a full backup.
My setup:
RaspberryMatic CCU3 with CCU-Jack as MQTT broker (over 200 MQTT entities).
Home Assistant fetches the data via MQTT integration unencrypted over port 1883 with username and password
The MQTT integration is configured in the UI
The entities are configured manually via mqtt.yaml text file
The problems are as follows:
After the update, I can switch an MQTT switch exactly once. The UI shows the change, but switching back is not possible. As soon as I reload the MQTT integration, I can switch once again, because the entities and their states are read in again.
In the MQTT explorer it can be seen that whenever I press the switch again, a command is sent, but this just always confirms the current state and does not switch. It’s as if the MQTT state is not being transmitted properly, but the MQTT Set command is.
What I have already done:
Reboot the system after the update.
Deleted MQTT integration after update and set it up again
Deleted MQTT integration, deleted mqtt.yaml, rebooted system and reinstalled everything
checked core logs → no peculiarities
Has anyone here perhaps had the same problem and can help?
I am unfortunately just trapped on 2023.4
The only thing I could find in the release notes is the following section:
The way how retained messages are processed has changed:
The way MQTT messages with a set retain flag are handled has changed such that existing
subscribers are no longer passed retained messages re-sent by the broker as a result of new subscribers subscribing to the same topic. Instead, retained messages re-sent by the broker are only passed to the new subscriber.
At least that would be the closest, since I set the retain flag on all entities. But still, as I understand it, this text passage should only apply when a new subscriber is added.
So I wouldn’t call this a change that affects my operation.
In the logs, as I said, I can’t find anything that indicates any errors in MQTT.
It just seems to me that it is not reading the state-topic correctly. So it doesn’t get that the state of the device has changed. But in the definition of the state-topic nothing has changed to my knowledge.
In an ideal scenario, the MQTT device will have a state_topic to publish state changes. If these messages are published with a RETAIN flag, the MQTT switch will receive an instant state update after subscription, and will start with the correct state. Otherwise, the initial state of the switch will be unknown . A MQTT device can reset the current state to unknown using a None payload.
I think that’s what I want to achieve.
Should that have something to do with the problem? Since it seems to be a general problem in MQTT and also affects sensors that don’t have a retain flag to configure, I don’t think it has anything to do with it.
And here after the update:
See my next post as I am only allowed to upload one image per post
After the update no status update comes back as described, which is why all further attempts want to turn off the switch, although it is already off.
All entities behave in the same way. Also my shellies (which are also sent to the Raspberrymatic CCU-Jack) do not update the sensors in the Home Assistant anymore.
I have now solved the problem by installing the Mosquitto addon in HomeAssistant and using the bridge function to synchronize the MQTT values of the CCU.
The HomeAssistant itself then no longer accesses the CCU to transmit the values, but the Mosquitto Broker Addon.
It seems that the problem is indirectly related to the CCU-Jack. When updating the HomeAssistant Core, perhaps a small thing in the MQTT protocol was changed, so that this can no longer interact with the CCU-Jack.
In any case, everything works now and I can update HomeAssistant again.