mega-20181006 Controllers issues

[axelmilb]

I'm a little confused about the new controller settings.
Because with ThingSpeak nothing matters or only the values of a sensor.
It's about the area that is new.


Minimum Send Interval: 100[ms]
Max Queue Depth: 10
Max Retries: 10
Full Queue Action: Ignore New or Delete Oldest
Client Timeout: 100[ms]

I and other newcomers would be grateful for their help

sorry for my bad English

[ao16]

Hi axelmilb,

I fully understand your concern - the same with me, I am also curious about these new settings
at ESPEasy-ThingSpeak-Settings that came in recently.

As far what I notice is that there seems to be a bug in the built 20181004
as my NodeMCU ESP cannot connect to TeamSpeak anymore.
The log says that a connection to the IP 184.106.153.149 is not possible and has failed.

Flashing the NodeMCU back to F/W V20180804 and all works again as it was working before.

I left all the new settings at the V20181004 in default as they came up after flashing.
The ThinkSpeak IP, Port, API-Key and also Message interval (15000ms at advanced tab)
were correctly taken over from the precious config after the F/W update so nothing has changed there.

Maybe these other new additional settings which came in cause this false connection to ThinkSpeak
and need to be additionally adapted?
Through Google I couldn't find any helpful information..the information there
was mainly outdated and from much earlier F/W-Version that even looked different than V20180804.

So any hint or help I also do appreciate.


best regards,

ao16

[axelmilb]

I thank you.

[TD-er]

The new settings are especially useful for Thingspeak.

Minimum Send Interval is the minimum time between two successive sends to the set endpoint of the controller
For ThingSpeak it must be 15 seconds (15000 msec) when you have a free account.
With such long intervals, it makes sense to set the "Full Queue Action" to "Delete Oldest" to make sure you get the latest values.
Then the "Max Queue Depth" should be low, like 1 or 2.

ThingSpeak is remote, so maybe 100 msec is a bit short then I guess. The old default timeout was 1000 msec, but I guess that may be a little too long.

The general idea about this queue system is to handle bursts of controller updates and also to keep the first collected readings, before the WiFi connection has been made.

[axelmilb]

Thanks for the answer will test this evening again, with a sensor it was not a problem but in the last test with a BMP280 and a DHT11 only the BMP280 data are transmitted.

[TD-er]

Maybe we should add another filter to this queue system to make sure the last value of a sensor is being kept.

[Domosapiens]

Indeed, for volatile data ... the last is the best!

[axelmilb]

Maybe we should add another filter to this queue system to make sure the last value of a sensor is being kept.

Maybe that's the solution.

Have still made a test but without success.
https://drive.google.com/file/d/1EP4Rk4 ... sp=sharing
https://drive.google.com/file/d/1Gh9MHd ... sp=sharing
https://drive.google.com/file/d/1VW-edp ... sp=sharing
And the logfile
https://drive.google.com/file/d/1L0ZqZD ... sp=sharing

Edit:
With MQTT, only the second value of each sensor arrives.

[ao16]

Thanks a lot for your explanation, TD-er, that was very helpful.
With your proposed settings, ThingSpeak works again - great

I assume as the minimum send interval is now set at the controller tab (15s for Thingspeak)
I can set the message interval in the advanced tab back to 100ms or 1000ms, right?

best regards,

ao16

[TD-er]

Yep, message interval should be low.
Since these changes to controllers it is not being used anymore as much as it was before.
It was blocking the entire node for the message interval duration, which is really bad.
That message interval setting was one of the reasons I changed the Controller behavior.