amemo06

amemo06

Hi Everyone,
maybe the below will help people facing random incorrect behaviors.
In sample from december 2016 /mysensors/MySensors/examples/RelayActuator/RelayActuator.ino, there is something which could be seen as a bug.

In my case, I have used that sample to control a lot of relais. I noticed some rare but really annoying errors. From time to time a relay got switched incorrectly.
Annoying and strange as coding was pretty straightforward. All relais are coded to act in pulse mode.

          digitalWrite(message.sensor-1+RELAY_1, RELAY_OFF);
          wait(1000);
          digitalWrite(message.sensor-1+RELAY_1, RELAY_ON);

And this is the reason of the bug.

Explanation.
During that second of wait, a lot of things may occurs. Due to the 'message' declaration, it is possible that the 'message' is getting changed.
Typically a ping may come and as result the 'message' is not anymore the same.

For that reason I would suggest the code to be changed a little bit.

void receive(const MyMessage &message_orig)
{
  MyMessage message;
  message = message_orig;

This way, the function works with a local copy and you are sure nothing can change during the processing.

Anyway, thanks for the sample it was nevertheless very helpful

amemo06

@gohan This is not in the original coding. I needed something like a wait in order to make a relay pulse.
The wait increases the risk or the frequency of the trouble. Removing it does not solves the issue.
Processing of the function will always take time. And the message can still changes before reaching the end like it is show in the second trace.

amemo06

@BulldogLowell said in Relay:

MsTimer2::

Thanks for the MSTimer, I was not aware of it.
And yes, definitively, having a wait() is probably the worst I could have written. Active wait cannot stay.
My intention, in the stuff I develop, was to remove it asap and probably by handling the wait time in the loop with flags.

Maybe I was not clear enough about my intention when I opened this thread. I have no issue with what I develop. I already had several ways to solves this. And now, I have a new one with MSTimer. Again thanks.

I only wanted to raise the fact void receive(const MyMessage &message) may lead to trouble as 'message' content may change during processing of that function.
And if, like many, you are not skilled enough to code/debug.., you will face erratic issues and real difficulty to understand what is going wrong.

amemo06

Hi @mfalkvidd,
thanks for the suggestion.
For the complete log, there will be some wait time. I will have to come back to the location and record it. It may takes days.
The only log I have was the last successful one.
I have some serial prints in each main function.
As it is visible in the log, I enter and leave properly in each.

before in and out,
setup in and out...
And there is a lot of activity about temperature sensors prior the presentation.
Each of these temperature reading are coming from the loop(). Each read do lead to a send(). So I was wondering if these send() could or couldn't be the reason of the random delay to execute the presentation? !
Considering without presentation being executed, the sends are useless !

0 MCO:BGN:INIT GW,CP=R-NGA---,REL=255,VER=2.3.1
4 MCO:BGN:BFR
Before_in:
Before_out:
684 GWT:TIN:IP=192.168.0.27
1687 MCO:BGN:STP
Setup_in:
Setup_out:
1688 MCO:REG:NOT NEEDED
1692 MCO:BGN:INIT OK,TSP=NA
Temp Sensor[5] tempidx[0]temp=29.30
Temp Sensor[6] tempidx[1]temp=43.70
Button sensor7 value=1
Waterpump button value1 send 0
Button sensor-1 value=1
Button sensor-1 value=1
Button sensor-1 value=1
Button sensor-1 value=1
Temp Sensor[5] tempidx[0]temp=29.20
Temp Sensor[6] tempidx[1]temp=43.60
Temp Sensor[5] tempidx[0]temp=29.30
Temp Sensor[5] tempidx[0]temp=29.20
Temp Sensor[5] tempidx[0]temp=29.30
Temp Sensor[6] tempidx[1]temp=43.50
Temp Sensor[6] tempidx[1]temp=43.60
33609 GWT:TSA:ETH OK
->presentation_in:

Nb temperature sensors=2
S01-P22 Relais 1
S02-P23 Relais 2
S03-P24 Relais 3
S04-P25 Relais 4
Present sensor temperature[5] idx_temp=0 : desc=S05-P36 Temp 1-Pisc
Present sensor temperature[6] idx_temp=1 : desc=S06-P36 Temp 2-Chauf
S07-P35 Moteur Pisc
<-presentation_out

33636 GWT:RFC:MSG=0;0;3;0;2;
33716 GWT:RFC:MSG=0;0;3;0;2;Get Version
34708 GWT:RFC:MSG=0;0;3;0;18;PING
Temp Sensor[6] tempidx[1]temp=43.50
Temp Sensor[6] tempidx[1]temp=43.60
Temp Sensor[6] tempidx[1]temp=43.50
44723 GWT:RFC:MSG=0;0;3;0;18;PING
54733 GWT:RFC:MSG=0;0;3;0;18;PING

amemo06

Hi,
I finished and installed one of my box to handle several stuff.
Description is below. I tested all independantly prior installation. All was looking quite fine. Function presentation() was called quite fast after reboot.
Now that I installed everything in the 'production place', I noticed it may take hours or days until domoticz succeed to connect to the arduino

Description of the sensors

Pool Temperature
Pool heating temperature
Water pump status (on or off)
4 relays to water some plants
sensor for soil humidity
some other stuf
Main material
arduino mega + ethernet shield. No radio.

Domotic server is domoticz

As written above, before I installed all the stuff, all was running quite fine.
Testing was running quite smooth
After reboot, function presentation() was called quite fast.

Now since I installed eveything and plugged all sensors, after reboot it could take hours before the function presentation() is called.

Any idea what I could have made wrong?

Initially my 1st thought was the power supply which could be too weak.
12v 1A which powers up 2 LM2596S.
1 LM2596 is for the arduino in 9v
1 LM2596 is for the 4 relay board with 5v
I just put a power supply 12v 3A. Nothing has changed.

So I plugged the laptop and found presentation() is either not called, either called a very long time after reboot.

What could be the issue?
Should I put a delay to avoid looking at sensors while waiting the presentation is performed? In other words, do nothing in the function loop() unless the presentation is called?

The code logic is as follow in code sequence

function before()
to initialize the Dallas temperature sensors and relays + some LEDs
function setup()
to setup the manual buttons, debouncers....
function presentation() <<-- this is the one just not called or called after a very long time.
to present the sketch and sensors
function loop()
to handle the temperature and the manual action to buttons THEN send message to the domoticz server whenever something has changed.
Typically there is always some temperature activity. Temperature changes quite often +/- 0.1°C
Finally a function receive()
It receives the manual action from domoticz server.

Any ideas or suggestion is welcome. Especially, if someone already faced the issue with function presentation() not called or called after a random long time.
Thanks

amemo06

@BulldogLowell said in Relay:

MsTimer2::

Thanks for the MSTimer, I was not aware of it.
And yes, definitively, having a wait() is probably the worst I could have written. Active wait cannot stay.
My intention, in the stuff I develop, was to remove it asap and probably by handling the wait time in the loop with flags.

Maybe I was not clear enough about my intention when I opened this thread. I have no issue with what I develop. I already had several ways to solves this. And now, I have a new one with MSTimer. Again thanks.

I only wanted to raise the fact void receive(const MyMessage &message) may lead to trouble as 'message' content may change during processing of that function.
And if, like many, you are not skilled enough to code/debug.., you will face erratic issues and real difficulty to understand what is going wrong.

amemo06

@gohan This is not in the original coding. I needed something like a wait in order to make a relay pulse.
The wait increases the risk or the frequency of the trouble. Removing it does not solves the issue.
Processing of the function will always take time. And the message can still changes before reaching the end like it is show in the second trace.

amemo06

@BulldogLowell No This is not the coding of the function which changes it. It is most likely the event which triggers it which may changes it.
I can show the coding with trace and trace result.

void receive(const MyMessage &message)
//void receive(const MyMessage &message_orig)
{
//  MyMessage message;
//  message = message_orig;
  Serial.println("receive_in:");
Serial.print("1st read:Sensor=");Serial.print(message.sensor);Serial.print(", getBool=");Serial.println(message.getBool());
  // We only expect one type of message from controller. But we better check anyway.
  if (message.type==V_STATUS) {
    // Change relay state
    if (message.getBool() == RELAY_ON){
      digitalWrite(message.sensor-1+RELAY_1, RELAY_OFF);
Serial.print("2nd read:Sensor=");Serial.print(message.sensor);Serial.print(", getBool=");Serial.println(message.getBool());
      wait(1000);
      digitalWrite(message.sensor-1+RELAY_1, RELAY_ON);
Serial.print("3rd read:Sensor=");Serial.print(message.sensor);Serial.print(", getBool=");Serial.println(message.getBool());      
    }
Serial.println("receive_out:");
}

Below is a normal trace

0;255;3;0;9;Eth: 0;0;3;0;18;PING
0;255;3;0;9;Eth: 0;1;1;0;2;1
receive_in:
1st read:Sensor=1, getBool=1
2nd read:Sensor=1, getBool=1
3rd read:Sensor=1, getBool=1
receive_out

So you see the ping which occured before the message I'm interested in
Now, because of the wait in the middle of the code, it may occurs the ping arrive in that period. Then the issue occurs.
See the trace with error.

0;255;3;0;9;Eth: 0;1;1;0;2;1
receive_in:
1st read:Sensor=1, getBool=1
2nd read:Sensor=1, getBool=1
0;255;3;0;9;Eth: 0;0;3;0;18;PING
3rd read:Sensor=0, getBool=0
receive_out

In the 3rd read, sensor value has changed and getBool returns also a different value.

Removing the wait or ensuring the function modules performs faster could reduce the risk. Still it will never be reliable.
Better is to have either a local copy of the message like I wrote in the original post. Or make immediately copies of the information from the message I'm interested in.

amemo06