Nevertheless, please paste the full YAML config as formatted text for all the MQTT sensors.
1 Like
mqtt:
sensor:
- name: "PV Ertrag Tag"
state_topic: "Wechselrichter/total/YieldDay"
unit_of_measurement: Wh
state_class: total_increasing
device_class: energy
unique_id: PV_Ertrag_Tag
At the moment this is the only sensor.
After not working, I decided to generate a sesor manually into the yaml, but as you can see it is also not working.
So the first sensor was auto-discovered but not working; and now you’ve created this manual one?
If this is your first mqtt: entry in your YAML, have you restarted HA? Are the screenshots above for this manual one or for the auto-discovered one?
1 Like
Exactly, first auto discovery, now manually into the yaml (Same bahvior). HA was restarted several times. A restart is causing that the Data gets transmitted once, but then never again, until the next restart. Screenshots are manual yaml.
And you have MQTT configured in HA? Here’s what mine looks like under the Integrations screen, with my broker being Mosquitto running in a separate Docker container from HA (i.e. not the HA add-on, same as you):
I’m not using mosquitto in HA. I’m using my own broker.
I’m quite sure that HA is not handling topics with retain flag set properly…
What broker is that ?
Its the Broker which my Homematic is using to bring MQTT to it. It’s called CCU Jack.
But nervertheless, when everything is working with MQTT Explorer, then it also has to in HA. Or not?
By the way, I’ve also subscribed to the topic with my Homematic and the the values are refreshing as they should.
It does in my installation.
Go to settings → Devices & Services → MQTT
Click configure
Under ‘Listen to a topic’, enter
Wechselrichter/total/YieldDay
and hit ‘Start listening’
As you can see in screenshot in start post, I’ve already done that and it is working.
But its working only once. The data appears one time and then never again. Mere less like a manual trigger.
CCU Jack called out a couple of times here. One person swapped it for Mosquitto and the problem went away.
I also used ccu-jack. The solution for me was to switch to another MQTT Broker, which is now running on my NAS instead of the Homematic CCU. With the new broker everything works again.
Integrations like Zigbee2Mqtt use retained configuration messages, this means that they survive a reboot, and popup when reconnecting. If there is a config error in these messages, thnx this will prevent MQTT from becoming available.
Maybe, but I need CCU Jack to bring the data to my Homematic, there is no other way. So I have this Broker anyway. I don’t want to have 2 different brokers in my system.
I would like to know the reason why this is not working. As I said, in MQTT Broker everything is fine, so there must be something in HA which is preventing it from refresing the values.
Here you can see that in MQTT Explorer Values are coming properly
Check your logs thoroughly: are there any relevant entries?
This topic describes a similar problem solved with an MQTT bridge:
1 Like
Already seen theese “Workarounds”, but try to find a soultion for it, not a workaround. It seems that HA have problems with Brokers which are not named Mosquitto…
Many people use HiveMQ and other brokers without issue. It is more likely an issue with CCU Jack.I see you have opened an issue:
2 Likes
Maybe, but what is against this assumption is the fact that wit MQTT Explorer everything works, so when the MQTT Integration would work like MQTT Explorer, I would have no issue…
Tryed to use the workaround with the Mosquitto Bridge… When I’ve prepared everything properly then there really seems to be something wrong with the protocol…
mosquitto version 2.0.18 running
2024-04-11 15:54:33: Connection Refused: unacceptable protocol version
2024-04-11 15:54:33: Client local.core-mosquitto.bridge-01 closed its connection.
2024-04-11 15:54:33: New connection from 127.0.0.1:48084 on port 1883.
2024-04-11 15:54:33: Client <unknown> disconnected due to protocol error.
It’s either HA not subscribing the CCU Jack topics correctly (unlikely as it works for other brokers), or CCU Jack not publishing to the subscribed HA client correctly when a subscribed topic receives a new message. Unlikely to be an authentication issue as it is publishing retained messages to HA when it connects.
Anything in the HA or CCU Jack logs that can shed light on this?
2 Likes
I use EMQx and have no issues with retained flags in HA. My guess is that since CCU Jack uses Go as it’s language, it’s doing something that may not be part of the standard 3.1.1 spec when it comes to the retain flag. I couldn’t find anything in the source code that highlighted the broker it uses (but it looks like it’s a Go version of MQTT).
That’s like comparing apples to oranges. MQTT Explorer and HA use completely different libraries to access MQTT brokers and may have differences in how they both handle the retain flag. I know that HA made changes last year(?) to how it handles the retain flag that I think might have been different than the 3.1.1 spec allows for (for 5.x broker support).
1 Like
I have a Solution now. I’m using the Mosquitto Broker in HA and the CCU Jack is working as a Bridge. I can live with that, but really curious why the Jack Broker is not working in HA. Placed an issue on CCU-Jack Project.
2 Likes