problems after last up date at firmware Development Build v3.4.0b2

[florin-laurentiu]

affter up grade to the last developement firmware as in the title, i have same problems:

• temperature sensors - DALLAS - are recognaized in the web ui interface just by their adress, not by the given name; if returned to a previous stable firmware, they cattch again their old names.
• also the Dallas sensor are recognaized on the Homeassistant system , but never up date the value; in fact values in degree Celsius is every time zero.
• in the solar web ui interface, there are some strange informations... see attached picture
• hc1 thermostat is not responding anymore in Homeassistant.

[proddy]

Is this after a v3.3 upgrade? Then looks like you have some stale data in your Mqtt broker. Use mqttexplorer to clean it out

Use the webui to rename sensors

And the solar is strange. Send over the results of /api/solar

[MichaelDvP]

The strange solar values for SM10 are (maybe accidential) copied from my build. I record them to examine the meaning. data11/12 is something regarding solar gain and boiler ww manipulation, Settings3/4 i first thought this is collector min/max with factor 10, but changing does not change the shutdown level. Looks like a hysteresis, but i need some days with stable sunshine to test. @florin-laurentiu You can use settings/customization to remove the values.

[florin-laurentiu]

the mentioned problems from top is begin to appear from the Development Build v3.4.0b1.

[MichaelDvP]

The update v3.3.x -> v3.4.x has a lot of changes that need some adaptation on your side.

• The dallas names are now stored in the new customization file and needs to be reentered.
• MQTT Discovery is not only HA, now, it is enhanced to other systems like domotics. You need to clear the stored (retained) values in your MQTT-Broker to allow HA to configure right.

[florin-laurentiu]

OK, I will work on this.

thank you!

On Fri, 28 Jan 2022 at 10:16, MichaelDvP @.***> wrote:

The update v3.3.x -> v3.4.x has a lot of changes that need some adaptation on your side.

• The dallas names are now stored in the new customization file and needs to be reentered.
• MQTT Discovery is not only HA, now, it is enhanced to other systems like domotics. You need to clear the stored (retained) values in your MQTT-Broker to allow HA to configure right.

— Reply to this email directly, view it on GitHub https://github.com/emsesp/EMS-ESP32/issues/335#issuecomment-1023982650, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ4QHRSDKIKGRLPIXXBVKFDUYJGFRANCNFSM5M6X672A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[bbqkees]

Would it be an idea to automatically clear all retained messages once with an upgrade from 3.3 to 3.4?

[florin-laurentiu]

in my opinion, yes.

On Fri, 28 Jan 2022 at 10:44, Kees @.***> wrote:

Would it be an idea to automatically clear all retained messages once with an upgrade from 3.3 to 3.4?

— Reply to this email directly, view it on GitHub https://github.com/emsesp/EMS-ESP32/issues/335#issuecomment-1024001410, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ4QHRRXX4YQ6M5UWOAUYITUYJJNDANCNFSM5M6X672A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[MichaelDvP]

Would it be an idea to automatically clear all retained messages once with an upgrade from 3.3 to 3.4?

Do you have a hint how to do this? The only way to remove retained messages from outside the broker is (afaik) to publish the topic with empty payload.

• We can add a list of all possible ha-topics from v2.x, 3.0, 3,1, 3.2, 3.3., not useful.
• We can subscribe to homeassistant/# and remove all received messages, but the broker should be set to publish on connect, this is afaik not standard, the user have to reconfigure the broker to make it work. I did not find a way to trigger this from client.

[bbqkees]

From what I know is that indeed you need to send an empty payload with the retain flag on (because only one message is retained per topic, sending an empty payload will erase the previous contents).

Doing it automatically after the update to 3.4 would give everyone a clean start. However, perhaps not everyone would like that.

[MichaelDvP]

Yes, but my problem is that we need to know what topic to send. We have to build a complete list of all entities ever used in all versions of emsesp and store all these old topics in v3.4 to remove them? There must be hundreds of these topics and a lot of work to pick them up manually from all commits.

[proddy]

I spent a few hours looking at this last year. I was looking through the MQTTExplorer source code to see how they browse through the topic tree. It's very hard so I gave up. There's a GH issue I created about it somewhere.

[MichaelDvP]

I'm not sure, but as far as i understand the broker should send all retained messages on subscribe. Then we can scubscribe on boot to homeassistant/# and publish back every message with empty payload and retain flag. This should clear all HA values on startup before the new HA messages are created. I have to setup a mosquitto to test, the ioBroker.mqtt seems not to be standard conform in this case, because it's also client and state-handler and all messages creates "retained" states (ioBroker entities).