ESP8266 and MQTT import on OLED issues

[Spacefan]

Hey guys,
first of: massive thanks to develops and the community. Awesome stuff and I am happily using a fleet of ESP8266 with BME280 sensors that publish over MQTT to a rpi running iobroker. I managed to display the local sensor values on such a esp node with an attach OLED display. So far so good.

I have been trying to display values from other nodes via the MQTT import. It works but is stuck after a while, because of the flash write cycle limit I suppose. Is there a way I can limit the import time frequency?

Or what is the easiest, nicest way to show mqtt sensor readings on a node, that is connected to iobroker?

all units run mega-20200410 and publish every 60s to iobroker. (I know this is quite frequent, but I am still in testing mode and will later switch to 600s or even longer)
Subscribing and pulling values only every 15 min would be totally fine for me, even less is fine if that solves the issue.

best regards and much thanks in advance for any help

[TD-er]

I really wonder how you can hit this limit here.
If you're using the Framed OLED plugin, you can simply write to the field without having to save once.
And you can also just refer to values like [bme#hum] or whatever task name and variable name you're using on the ESP.

[Spacefan]

hey thanks for your reply, ok I get your point. Yes its the OLED SH1106 framed I am using.

But maybe than it has to do with the mqtt import. Does it write to flash or does it just take the value over mqtt and keeps it in RAM?
I don't see any option to set a time how often to pull info from mqtt topics. Or doesnt it matter at all?

[TD-er]

It should not write to flash for every request.

MQTT doesn't work with "pulling", as you subscribe to a topic and get notified when something has been published in that topic.
That's the task of the broker.

If you need to limit it, you can do it in the rules by storing the last value in a variable and periodically write the value to the display.
But that's rather complex and really not needed.

Can you try one of the latest builds, to see if you still hit this write limit?
Also please show your rules and/or the config of your Framed OLED task.

[Spacefan]

ok from what I currently get is that it only shows the mqtt import value after reboot and then gets no more further updates. So probably that is my issue here.
Is there any obvious wrong setting?



Build:⋄ 20110 - Mega
System Libraries:⋄ ESP82xx Core 5d3af165, NONOS SDK 2.2.2-dev(38a443e), LWIP: 2.1.2 PUYA support
Git Build:⋄
Plugin Count:⋄ 46 [Normal]
Build Origin: Travis
Build Time:⋄ Aug 29 2020 16:09:41
Binary Filename:⋄ ESP_Easy_mega_20200829_normal_ESP8266_4M1M

Screen Shot 2020-09-11 at 10.26.10.png (196.96 KiB) Viewed 8793 times

Screen Shot 2020-09-11 at 10.33.29.png (205.82 KiB) Viewed 8793 times

Screen Shot 2020-09-11 at 10.33.56.png (176.32 KiB) Viewed 8793 times

Screen Shot 2020-09-11 at 10.34.15.png (228.2 KiB) Viewed 8793 times

Screen Shot 2020-09-11 at 10.34.32.png (262.06 KiB) Viewed 8793 times

Screen Shot 2020-09-11 at 10.34.58.png (152.65 KiB) Viewed 8793 times

[TD-er]

Please don't use non-ASCII characters in the variable names (and task names)
I think the name matching fails on the variable name you use.

[Spacefan]

ok changed it, but it does not make it better.
It only gets the values from the broker once after you enable it or reboot, then stops updating (just as with the old value name, so I guess thats not difference)

I get the following log starting right after a reboot via "tools"
So it seems to get it only twice, although the iobroker has new values every 60s. So it does not properly send it to the ESP with the display or any clue?

---------------------

2383: IMPT : Connected to MQTT broker with Client ID=Sonnenhof_in_16-Import1
2412: IMPT : [MQTT#temp] subscribed to Sonnenhof_out_13/BME280/Temperature
2413: IMPT : [MQTT#humidity] subscribed to Sonnenhof_out_13/BME280/Humidity
2659: UDP : Start listening on port 130
2659: firstLoopConnectionsEstablished
2676: MQTT : Intentional reconnect
2724: MQTT : Connected to broker with client ID: Sonnenhof_in_16_16
2728: Subscribed to: Sonnenhof_in_16/#
2736: WD : Uptime 0 ConnectFailures 0 FreeMem 13848 WiFiStatus WL_CONNECTED
2804: NTP : NTP replied: delay 31 mSec Accuracy increased by 0.134 seconds
2805: Time set to 1599816886.134 Time adjusted by 1200.28 msec. Wander: 0.33 msec/second
2809: Local time: 2020-09-11 11:34:46
2852: IMPT : [MQTT#temp] : 19.49
2942: IMPT : [MQTT#humidity] : 45.00
5619: BME280: Apply temp offset -0.40C humidity 54.98% => 55.66% temperature 19.79C => 19.39C dew point 10.25C
5636: BME280 : Address: 0x76
5637: BME280 : Temperature: 19.39
5637: BME280 : Humidity: 55.66
5638: BME280 : Barometric Pressure: 1018.05
32147: WD : Uptime 1 ConnectFailures 0 FreeMem 16104 WiFiStatus WL_CONNECTED
62147: WD : Uptime 1 ConnectFailures 0 FreeMem 15992 WiFiStatus WL_CONNECTED
92147: WD : Uptime 2 ConnectFailures 0 FreeMem 15992 WiFiStatus WL_CONNECTED
95750: IMPT : [MQTT#temp] : 19.29
95848: IMPT : [MQTT#humidity] : 45.00
122147: WD : Uptime 2 ConnectFailures 0 FreeMem 15976 WiFiStatus WL_CONNECTED
152147: WD : Uptime 3 ConnectFailures 0 FreeMem 15976 WiFiStatus WL_CONNECTED
182147: WD : Uptime 3 ConnectFailures 0 FreeMem 15976 WiFiStatus WL_CONNECTED
212147: WD : Uptime 4 ConnectFailures 0 FreeMem 15976 WiFiStatus WL_CONNECTED
242147: WD : Uptime 4 ConnectFailures 0 FreeMem 15976 WiFiStatus WL_CONNECTED
272147: WD : Uptime 5 ConnectFailures 0 FreeMem 15944 WiFiStatus WL_CONNECTED
302147: WD : Uptime 5 ConnectFailures 0 FreeMem 15944 WiFiStatus WL_CONNECTED
315595: BME280: Apply temp offset -0.40C humidity 55.00% => 55.69% temperature 19.84C => 19.44C dew point 10.30C
315612: BME280 : Address: 0x76
315612: BME280 : Temperature: 19.44
315613: BME280 : Humidity: 55.69
315613: BME280 : Barometric Pressure: 1018.05
332147: WD : Uptime 6 ConnectFailures 0 FreeMem 15928 WiFiStatus WL_CONNECTED
362147: WD : Uptime 6 ConnectFailures 0 FreeMem 15848 WiFiStatus WL_CONNECTED
392147: WD : Uptime 7 ConnectFailures 0 FreeMem 15928 WiFiStatus WL_CONNECTED
422147: WD : Uptime 7 ConnectFailures 0 FreeMem 15928 WiFiStatus WL_CONNECTED
452147: WD : Uptime 8 ConnectFailures 0 FreeMem 15928 WiFiStatus WL_CONNECTED
482147: WD : Uptime 8 ConnectFailures 0 FreeMem 15928 WiFiStatus WL_CONNECTED
512147: WD : Uptime 9 ConnectFailures 0 FreeMem 15928 WiFiStatus WL_CONNECTED

[TD-er]

Are you 100% sure the topic you subscribe to is correct?
For example in your screenshot you have a double unit number (Sonnenhof_out_16_16), so please check the controller settings of unit 13 to see what it suggests as topic string.

[Spacefan]

That double unit number is not input by me, seems to be a flaw of the page there? Because in iobroker it is also listed as such "Sonnenhof_out_13/BME280/Humidity"

If it would be the wrong topic, how can it correctly read the values in the 1st instance it does work after reboot? (yes I checked it is the correct value for that timestamp in iobroker)

So I don't know how this works, but I assume if it correctly gets values once, there is no issue with names etc right?
It rather must be something with the cooperation of MQTT import and broker.

[TD-er]

Sure, if it gets imported once, you would expect it to be working OK.
But it wouldn't be the first time another node may also write to the same topic with a completely different interval, so I wanted to make sure that whatever you're looking at is at least correct

I haven't used MQTT import myself, so I can't tell you right now what could be the issue here.
Do you have the controller with the MQTT settings active?
What happens if you send rather frequently to that controller (on a different topic of course) with an interval of say 10 seconds?

Also check to see if the sending node (13) has a stable connection. If that one constantly keeps loosing its WiFi connection, then not a lot is sent to the broker.

About the "double unit number", that's caused by the default config "Append Unit Number to hostname" on the Config tab.

[Spacefan]

Hm
yes I am aware of the "append unit number" which would explain 1 number (which is how it appears in iobroker etc) but the double number seems to be a bug for that field on that page.

Wifi connection is stable, readings of the unit 13 are reliably in iobroker. I have tried this with other units next to Wifi AP, also the same.
The controller is active, otherwise they both could not publish to iobroker :/

I tried with 5s measuring time but it does not help

Haha damn would be too easy if it just works
I appreciate your feedback and ideas

[TD-er]

Maybe someone else with a bit more experience on the MQTT import plugin can offer some more ideas.
Otherwise I have to make a test setup using MQTT import myself to see what may be happening here.
But that may take a while as I don't have a lot of time this weekend.