Energy Pulse Meter strange behaviour

[mbj]

For testing purpose I am basically using the Arduino blink program to generate IR pulses to the sensor and everything seems to be working. Have checked the pulse on the oscilloscope and it looks OK. The debug info shows that the sensor starts with this message:

sensor started, id 21
send: 21-21-0-0 s=255,c=0,t=17,pt=0,l=5,st=ok:1.4.1
send: 21-21-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
send: 21-21-0-0 s=255,c=3,t=11,pt=0,l=12,st=ok:Energy Meter
send: 21-21-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 21-21-0-0 s=1,c=0,t=13,pt=0,l=5,st=ok:1.4.1
send: 21-21-0-0 s=1,c=2,t=24,pt=0,l=5,st=ok:1.4.1

but after a short wait it begins to spit out endless amounts of a single message :

send: 21-21-0-0 s=1,c=2,t=24,pt=0,l=5,st=ok:1.4.1

I have tried to decipher the message using the http://www.mysensors.org/build/serial_api link but since I am a beginner with the MySensors software I can figure out what is causing this endless transmittal of this message. Has anyone else experiences something similar and found a solution.
I attach an example output.

I am using the MQTT gateway and the issue seems to be with the V_VAR1 variable.

[hek]

The pulse meter example tries to request last known meter value from controller at startup.

Not sure if requesting stuff works when using MQTT?

[mbj]

Thanks, I guessed that was the cause but did not expect a flood of requests to the gateway if the answer did not arrive. Guess an error checking can be built into the code to avoid stressing the gateway.

I am using the OpenHab controller and have a feeling that I need to make a fix there. Right now I am not sure about the"howto" because I have just started to learn using OpenHab too. Not an easy starting point being new to all of it
Simpler sensors which just reports a value back (like temperature) are easier to get working via MQTT,

[mbj]

I have the sensor working with OpenHab now but there are bits and pieces to learn before getting there. As described above the sensor flood the gateway with a repeated message because it is not receiving anything from the Gateway/Controller (in my case MQTT and OpenHab) and it is not so easy to get this communication going.

First of all a message of type V_Var1 sends a string message ("1.4.1") to the gateway but once the communication is working the same message type is used to transmit pulse count of type long. With the limited knowledge I have of OpenHab I have not been able to declare items which reacts correctly to V_VAR1 being a string with content "1.4.1" sometimes and then a long integer pulsecount number other times.

The workaround became to use a message type V_VAR2 for the initial string variable and then V_VAR1 for the counter.

Secondly, the controller takes a fair bit of time to answer the initial request for the pulse count stored by the controller. This means that the execution of the code often but not always ends up in a "catch 22" type situation. To get everything running with any stability I have commented out following code part (Obs, as said I am using V_VAR2 for this message):

/* else if (sendTime && !pcReceived) {
// No count received. Try requesting it again
gw.request(CHILD_ID, V_VAR2);
} */

Thirdly the question is if all this transmitting of the pulse count is of any value. My understanding is that having it does not make anything better because:

1 In a situation where the sensor (or the whole system) stops working nobody can tell how many pulses where lost. So a start-up value from the controller is of no help, the value received must be wrong.
2 If the sensor works and the gateway and/or the controller stops the pulse count will remain correct internally in the sensor and the values transmitted to the controller are not used.

Skipping the pulse count transmittal to the gateway would simplify the sensor communication a lot. An internal start up value of zero pulses would not be any worse that an erroneous pulse count received from the controller in cases where the sensor starts up after a failure.

I may have misunderstood the function so I hope for comments.

[mbj]

I have tried to get the "original" code for the energy sensor working and found one reproducible option. Whether the nano is fed from a 5V USB plug or a laptop does not matter, it still hangs after the initial request for input from the gateway. It can send to the gateway but does not receive the start-up count which the gateway sends.

But the very strange thing is that when I hook up the laptop and open the Arduino serial monitor the sensor starts reading from the gateway and is working fine. When I stop the serial monitor it quits working again. This behavior is reproducible. The auto reset when the serial monitor starts does some magic which is lost when the monitor stops. Pressing the reset switch does not make the nano work so these resets works differently.

This is tested for two different nanos with two different radios of the + version and behaviour is identical. Seems to be something in the underlying code.

Does anyone have any suggestions?

[hek]

Unless there is a previously un-detected bug in the power meter sketch** the only thing that comes to mind is a powering issue**.

Is it only this sketch that is problematic?

The arduino still spits out the debug prints even if serial monitor is "disconnected". So the behavior should really not differ.

[mbj]

Same behavior from several different USB plugs (up to 2A), one laptop and a desktop. Tested with the antenna chip as well as the without antenna one. Gateway and sensor less than one meter apart as well as about 10 m away tested.

I have a Mysensors temperature sensor attached to same MQTT gateway and this works perfectly well.

Sending messages always work but not receiving the start-up pulsecount or other incoming messages unless the serial monitor is running

Btw, I am feeding the radio from Nano 5V to a socket adapter plate like this one http://www.ebay.com/itm/200960749614?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

[mbj]

Referring to the response from hek (thanks hek) I started to play with the powering and also added decoupling capacitors to gateway and sensor. The situation has improved but it is not yet 100%. I will check what the output from the various power sources look like but apparently there is something which can be partly remedied by a capacitor. No other power connected devices show any problems so these radio circuits must be really sensitive.

[BulldogLowell]

@mbj said:

...so these radio circuits must be really sensitive.

They eat a lot of power...

[ericvdb]

@mbj said:

Btw, I am feeding the radio from Nano 5V to a socket adapter plate like this one http://www.ebay.com/itm/200960749614?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

You do know that the NRF is 3.3V only (with 5V tollerant IO's) ?

[mbj]

@ericvdb
Yes, I know about the 5V. But the adapter brings it down to 3.3V for the radio, that is the reason for using it and the adapter is equipped with the AMS 1117 3.3V chip. Seems to work OK but I really do not have any hard facts to prove it.

One thing I may test is to wire the 5V also directly to this adapter instead of taking it out from the Arduino 5V pin. This is to find out if this Arduino Nano clone might have too small capacity for feeding the radio at certain occasions.