Serial MCU controlled dimmer/relay - Initial delay of 2-3sec

[Micha_he]

I've flashed two MOES-Wifi-Dimmer with the pre-compiled filmware (I've also tested the new version from 9th february) from @enesbcs.

The devices are configured as follows:

dim1gz_devices.jpg (26.66 KiB) Viewed 14605 times

I've simplified the rules for a test to:

Code: Select all

on System#Boot do
  Relay,0,0
endon

on MQTT#Connected do
  publish /%sysname%/Dimmer/Dimmwert,[Dimmer#Dimmwert]
endon

on Eingang#Status=1 do
  if [Var#1]=1
    Relay,0,0
    Let,1,0
  else
    YDim,17
    Let,1,1
  endif
endon

on GetState do
  publish /%sysname%/status/LWT,Connected
  publish /%sysname%/Dimmer/Dimmwert,[Dimmer#Dimmwert]
endon

My problem is:

If I switch the dimmer on after some unused time, the first YDim-command needs 2-3sec to execute. Same with Relay-command and also if I execute it from tools/command.
After the first switch operation is executed, the next toogles are quick. Same, Relay-/YDim-command via tools/command. After some minutes have gone, the problem is present again at the next switch-on event.

Any ideas why ???

[TD-er]

Try enabling Gratuitous ARP in Tools -> Advanced (at the bottom of the page)

[Micha_he]

Improves this also communication beween the ESPEasy-system (and plugin) and the serial-connected MCU from the dimmer ??? Or the processing speed of the rules ?
The connection between browser and ESPEasy is smooth and fast.

[TD-er]

The only thing it may improve is the initial connection time via wifi.
Problem is that the network switches may "forget" to what port a device is connected.
To find the host which has IP xx.xx.xx.xx, ARP packets are sent. But the problem is that sometimes the ESP never receives these ARP packets and thus requests (or replies) to the ESP will not arrive.
If the ESP does "announce" itself more often on the network, via Gratuitous ARP packets, then the chance of being "forgotten" is less likely and thus the initial connection attempts to the ESP will go much and much faster.

Typical time-to-forget for MAC addresses in switches is 30 sec - 30 minutes and depends on the manufacturer of the switch and the number of hosts in the network (MAC tables are not infinite large)

[Micha_he]

But then the 'Gratuitous ARP' settings shouldn't be important anymore, if I logged in to the web interface some seconds before I executed the command via Tools-page or the lokal, mechanical switch is used.

But,... I'll test it later today.

[Micha_he]

There's no 'Gratuitous ARP' under Tools/Advanced. Maybe because it's a custom git version !?

[Micha_he]

Now, with new (updated source code), custom build and active 'Periodical send Gratuitous ARP', unfortunately nothing has changed

[TD-er]

Now, with new (updated source code), custom build and active 'Periodical send Gratuitous ARP', unfortunately nothing has changed

Hmm too bad.
Thanks for testing though.

[Micha_he]

Maybe a problem at the dimmer-MCU. I checked the serial data and the byte sequence is always send quick. Only the light-output is late switched on. Firmware bug ?

[ThomasB]

Maybe a problem at the dimmer-MCU. I checked the serial data and the byte sequence is always send quick. Only the light-output is late switched on. Firmware bug?

Even with the ESPEasy's serial log disabled, maybe some unexpected serial activity occurs when the system is idle. And maybe it temporarily confuses the dimmer-MCU. Just a thought.

So monitor the serial data sent by ESPEasy for several minutes. During this time do NOT send any dimmer-mcu commands (disable any rules that could do this). Does the serial port Tx & Rx remain idle? If you see any mystery data then that might be what is affecting the dimmer-MCU.

And while at it, visit Tools=>Advance=>Serial Log Level and confirm it is set to None.

Also confirm that your ESPEasy node is not randomly rebooting. Each reboot sends startup messages to the serial port that cannot be disabled. And perhaps this serial activity could temporarily confuse the dimmer-MCU.

Beyond that I would tend to agree that the dimmer-MCU has a firmware bug.

- Thomas

[Micha_he]

Even with the ESPEasy's serial log disabled,...

Yes, the plugin disable it and I've multiple controlled that. And it remains disabled during the test also.

So monitor the serial data sent by ESPEasy for several minutes. During this time do NOT send any dimmer-mcu commands (disable any rules that could do this). Does the serial port Tx & Rx remain idle?

No, I can't see anything in the terminal for several minutes.

And while at it, visit Tools=>Advance=>Serial Log Level and confirm it is set to None.

Yes, definitely

Also confirm that your ESPEasy node is not randomly rebooting.

No, it doesn't reboot while my tests.

But thanks for your comments. Does anyone have information about a possible firmwareupdate for the MCU (probably STM8S003F3) ?
If I found some time next week, I'll flash Tasmota again and look if the problem exists there too.

[TD-er]

Even with the ESPEasy's serial log disabled, maybe some unexpected serial activity occurs when the system is idle. And maybe it temporarily confuses the dimmer-MCU. Just a thought.
[...]

I looked in the code for serial activity and indeed in some of the commands there is a call to serialPrintLn(), which does not need to be there.
On the other hand, it is adding to the serial buffer, which is supposed to be used only for logging purposes, so this should not be flushed to the serial port when it is disabled.
Maybe the commands should be padded with some termination string, or else the board will wait for a timeout?
Or the data is not actively flushed and "terminated" before sending a new command?
This could also lead to timeout waits if somehow noise is picked up by the board and the board is waiting for the rest of that command?

[ThomasB]

I looked in the code for serial activity and indeed in some of the commands there is a call to serialPrintLn(), which does not need to be there.
On the other hand, it is adding to the serial buffer, which is supposed to be used only for logging purposes, so this should not be flushed to the serial port when it is disabled.

Just a general question: Is there any concern about the serialPrintLn() buffer if it becomes full because logging is disabled? Does that create a blocking event or other unexpected issue? Or is new log data simply discarded when the buffer is full?

Does anyone have information about a possible firmwareupdate for the MCU (probably STM8S003F3) ?

I have another idea that might be less work. You observed that the 2-3 delay does not occur until the dimmer-MCU has been idle for a long time. So maybe you can use that behavior to your advantage.

Here's my workaround idea: Write a ESPEasy timer rule that periodically sends a dimmer-MCU command. For example, the timer event could refresh the last used YDim value. Think of it as poking a sleepy guard dog with a stick so it stays awake and alert.

- Thomas

[TD-er]

I looked in the code for serial activity and indeed in some of the commands there is a call to serialPrintLn(), which does not need to be there.
On the other hand, it is adding to the serial buffer, which is supposed to be used only for logging purposes, so this should not be flushed to the serial port when it is disabled.

Just a general question: Is there any concern about the serialPrintLn() buffer if it becomes full because logging is disabled? Does that create a blocking event or other unexpected issue? Or is new log data simply discarded when the buffer is full?
[...]

The buffer is somewhat dynamic.
So it will empty old ones and will not use more memory than practical available.
Also it will not add to it when it is known there will be no-one to read it.

Still, not sending to the serial log is best when you do not intent to read it as it will also not generate logs of levels no log output will read.

[Micha_he]

Problem localized !

It isn't the COM-buffer, not the log or the MCU-firmware. Also not the rule, plugin or ESPEasy-source...

The problem was the dimmable LED-driver in my (new) ceiling lights. They have a soft start from power-off-state

[ThomasB]

The problem was the dimmable LED-driver in my (new) ceiling lights. They have a soft start from power-off-state

A 2-3 sec delay before the light turns on seems like a badly implemented soft start feature. But good to hear you resolved the problem.

So it will empty old ones and will not use more memory than practical available.
Also it will not add to it when it is known there will be no-one to read it.

Thanks for the reassurance that there are no bad side affects if ESPEasy talks to itself.

- Thomas

[TD-er]

[...]
Thanks for the reassurance that there are no bad side affects if ESPEasy talks to itself.

Well the schizophrenic feature has been tested very well, so that should work just fine

[ThomasB]

That's what they want you to believe. Pardon me while I adjust the tin foil hat on a NodeMCU.

- Thomas

[Micha_he]

A 2-3 sec delay before the light turns on seems like a badly implemented soft start feature.

Two more days of testing... New insights !
It's not a soft-start feature of the led-driver. The led-driver is start quick, when the dimmer switch from 0% to 100%. But start delayed, if it the dimmer switch on with 20%.

Solution: I work with a short, time-dependent (0-200ms) boost-switch-on. Looks like it works.