Hi all,
is this well known or do i have to change anything in order to keep my Victron Energy System (MQTT-Server behind on a BeagleBone Machine) sending data to Openhab.
I did not change the Thing-Configuration at all (migrated automatically) but it only works directly after an OH Restart…and after less than an hour it stops forever. a parallel MQTT.fx session (also subscribe) works fine. does not stop.
Bridge mqtt:broker:mivenusgx [ host="192.168.1.95",port=1883,secure=false,clientID="openhab" ] {
Thing topic victron "Victron ESS" {
Channels:
Type number : PowerTotal "Power total [%.1f W]" [ stateTopic="N/0c1c5xxxe38/grid/30/Ac/Power", transformationPattern="JSONPATH:$.value" ]
Type number : VeBatSoc "LiFePo4 SoC [%d %%]" [ stateTopic="N/0c1c5xxxxe38/system/0/Dc/Battery/Soc", transformationPattern="JSONPATH:$.value" ]
Type number : VeBatSocLimit "LiFePo4 SoC Limit [%d %%]" [ stateTopic="N/0c1c5xxx1e38/settings/0/Settings/CGwacs/BatteryLife/SocLimit", transformationPattern="JSONPATH:$.value" ]
Type number : VeBatState "LiFePo4 State [%d]" [ stateTopic="N/0c1c5xxx1e38/settings/0/Settings/CGwacs/BatteryLife/State", transformationPattern="JSONPATH:$.value" ]
Type number : VeBatPower "LiFePo4 Power [%.1f W]" [ stateTopic="N/0c1xxxx11e38/system/0/Dc/Battery/Power", transformationPattern="JSONPATH:$.value" ]
Type number : VeBatAmps "LiFePo4 Amps [%.1f A]" [ stateTopic="N/0c1cxxx11e38/system/0/Dc/Battery/Current", transformationPattern="JSONPATH:$.value" ]
Type number : VeBatVolt "LiFePo4 Voltage [%.1f V]" [ stateTopic="N/0c1cxxxx1e38/system/0/Dc/Battery/Voltage", transformationPattern="JSONPATH:$.value" ]
Type number : VeBatTemp "LiFePo4 Temp [%.1f °C]" [ stateTopic="N/0c1xxx11e38/system/0/Dc/Battery/Temperature", transformationPattern="JSONPATH:$.value" ]
Type number : VeSysState "ESS System State [%d]" [ stateTopic="N/0cxxx11e38/system/0/SystemState/State", transformationPattern="JSONPATH:$.value" ]
Type number : VeACkWhFor "NG5 Energy Import [%.2f kWh]" [ stateTopic="N/0c1cxxx111e38/grid/30/Ac/Energy/Forward", transformationPattern="JSONPATH:$.value" ]
Type number : VeACkWhRev "NG5 Energy Export [%.2f kWh]" [ stateTopic="N/0c1xxx11e38/grid/30/Ac/Energy/Reverse", transformationPattern="JSONPATH:$.value" ]
}
}
I’m not sure, but it looks like this has something to do with it…but what does this mean, not easy to make a rime out of this.
Ive now updated the log level for MQTT to TRACE and DEBUG, but still the messages do not show any additional information. Anyone able to help why this is happening…
still digging…when restarting i see strange messages that i completely do not understand.
I have no homie or homeassistant installed at all…simply migration from OH2.5.12
2021-06-01 08:38:20.157 [WARN ] [g.mqtt.handler.AbstractBrokerHandler] - Tried to unsubscribe org.openhab.binding.mqtt.homeassistant.internal.discovery.HomeAssistantDiscovery@1d3fc80 from discovery topic milight/states/# on broker mqtt:broker:mivenusgx but topic not registered for listener. Check discovery logic!
2021-06-01 08:38:20.395 [WARN ] [g.mqtt.handler.AbstractBrokerHandler] - Tried to unsubscribe org.openhab.binding.mqtt.espmilighthub.internal.discovery.EspMilightHubDiscoveryService@865c7f from discovery topic homeassistant/# on broker mqtt:broker:cloudmqtt but topic not registered at all. Check discovery logic!
2021-06-01 08:38:20.396 [WARN ] [g.mqtt.handler.AbstractBrokerHandler] - Tried to unsubscribe org.openhab.binding.mqtt.espmilighthub.internal.discovery.EspMilightHubDiscoveryService@865c7f from discovery topic homeassistant/# on broker mqtt:broker:mosquitto but topic not registered at all. Check discovery logic!
2021-06-01 08:38:20.396 [WARN ] [g.mqtt.handler.AbstractBrokerHandler] - Tried to unsubscribe org.openhab.binding.mqtt.espmilighthub.internal.discovery.EspMilightHubDiscoveryService@865c7f from discovery topic homeassistant/# on broker mqtt:broker:mivenusgx but topic not registered at all. Check discovery logic!
2021-06-01 08:38:20.397 [WARN ] [g.mqtt.handler.AbstractBrokerHandler] - Tried to unsubscribe org.openhab.binding.mqtt.espmilighthub.internal.discovery.EspMilightHubDiscoveryService@865c7f from discovery topic +/+/$homie on broker mqtt:broker:cloudmqtt but topic not registered at all. Check discovery logic!
2021-06-01 08:38:20.397 [WARN ] [g.mqtt.handler.AbstractBrokerHandler] - Tried to unsubscribe org.openhab.binding.mqtt.espmilighthub.internal.discovery.EspMilightHubDiscoveryService@865c7f from discovery topic +/+/$homie on broker mqtt:broker:mosquitto but topic not registered at all. Check discovery logic!
2021-06-01 08:38:20.398 [WARN ] [g.mqtt.handler.AbstractBrokerHandler] - Tried to unsubscribe org.openhab.binding.mqtt.espmilighthub.internal.discovery.EspMilightHubDiscoveryService@865c7f from discovery topic +/+/$homie on broker mqtt:broker:mivenusgx but topic not registered at all. Check discovery logic!
Do you have multiple MQTT-broker in your OH3? seems at least three are somehow needed:
mqtt:broker:cloudmqtt
mqtt:broker:mosquitto
mqtt:broker:mivenusgx
you could log into your broker, check the logs and check the connections to see, if OH3 is still connected and work from there.
But my advice would be to:
migrate the file-based configuration to UI-based configuration
yes, it’s effort - but worth it!
in the process you should
3.1. configure your MQTT-broker
3.2. configure your MQTT-channels with that broker
and it should run smoothly. I don’t know what happens via “automatic migration”, but as I migrated my remote openHAB installation from OH2 to OH3 I also encountered some incompatibilities with my old things/items/rules files, and I migrated all of them to UI-based configuration - and now it works.
Thanks. your message was the final mindchanger required to switch back to 2.5.12 by simply SDcard swapping. I’m not sure how HA e.g. does manage major release changes, but with OH every bigger release change means a lot of pain for the “simple” user as you can see from the discussions/questions here. I really really hope that after skipping 1.x bindings now things will become more “stable”.
Will start a parallel setup as you said, bind 2.0 to 3.0 machine and put things together step-by-step.
From my standpoint, migration simply does not work if you have more than a few simple items and not many bindings.
Agreed → a no-hazzle migration would be great. With OH3 the “old” way as OH1 handled things was thrown out as a major breaking change - along with a lot of other minor breaking changes.
IMHO, was the effort to handle each use case for migration from years of “dual use” (OH1, OH2, files, PaperUI, DSL rules, NewRuleEngine, …) too much to handle in the openHAB openSource community. I have a relatively big installation I would say - and it took me about 2days of intensive work in the new UI to get my system up and running from OH2 to OH3. Yes it’s effort, but I’d say it’s worth it as OH3 offers more than I’ve seen in comparable solutions - ok given it is still not 100% failsafe for noobs and as you call it “simple” users…
The warnings indicate that OH was aware of but unable to receive a message published to a topic it subscribed to and because the message was QOS 0, it dropped the message. Remember in MQTT that:
QOS
Meaning
0
At most once; if the message isn’t received drop it
1
At least once; if the message isn’t received try again, message may be received more than once
2
Exactly once; if the message isn’t acknowledged, try again until acknowledged
So the warning it telling you something is going wrong with OH that is making it aware that messages are being published but unable to process those messages. Most likely this would be caused by a lack of resources, perhaps network congestion or the CPU is pegged or RAM is full and OH is running out of swap space.
I don’t know MQTT.fx. It would be interesting to see if it too is dropping messages. That would indicate a general MQTT problem. Note that dropping QOS 0 messages are not an error. If delivery needs to be ensured, you need to use QOS 1 or 2.
An issue was filed for that and a fix implemented some weeks back. It’s a bug and you can ignore it. Those logs will go away when you upgrade to OH 3.1.
Based on the people who come to OH from HA, HA is far worse.
Note though that the longer you take to upgrade/migrate with any software the harder and more work it will be to upgrade. If one upgrades early and often the number of changes is relatively small and easy to deal with. If one waits years between upgrades the number of changes is huge and it becomes really hard just because there are so many. The MQTT 1.x binding has been deprecated for about two years now.
But note that I see nothing here in the behavior or the warning messages reported to indicate there is anything at all wrong with your OH MQTT configuration. In this case UI verses text based MQTT Things is a red herring. There is something wrong with OH or the machine that OH is running on. For some reason it can’t keep up with the QOS 0 messages and the reason it can’t do that likely lies outside of MQTT itself. As I mentioned, CPU at 100%, network problems, or memory problems could all cause this.
To be fair, the writing was on the wall for about two years that the 1.x bindings were not going to be supported in OH 3. And even when OH 2.0 came out all those years ago the stated goal was to replace all the 1.x bindings with 2.x bindings. And even so, the Remote openHAB binding was created primarily to allow those users who did not want to or could not give up the their 1.x bindings to continue to run them in an OH 2.5 instance and expose those Items to OH 3 in a pretty easy manner. It’s not like the devs didn’t give plenty of warning an no other options when it comes to 1.x bindings. And since no one stepped up to maintain the 1.x compatibility layer in OH 3 it was abandoned.
Anyway, back to the original problem. What are the states of the MQTT Things? Are they showing ONLINE in the UI after that hour where it stops? Are you only receiving messages or are you publishing too? If publishing do those messages make it through?
