Energy Meter Pulse Sensor - "lost parent / find parent" and VAR1

[bjornhallberg]

So I soldered up the pulse sensor and tested it on the bench with some peculiar results. It keeps going on and on with the gateway (which is two feet away literally). Has this something to do with V_VAR1 being fetched and not existing?

sensor started, id=9, parent=0, distance=1
send: 9-9-0-0 s=255,c=0,t=17,pt=0,l=3,st=fail:1.4
send: 9-9-0-0 s=255,c=3,t=6,pt=1,l=1,st=fail:0
read: 0-0-9 s=255,c=3,t=6,pt=0,l=1:M
send: 9-9-0-0 s=255,c=3,t=11,pt=0,l=12,st=fail:Energy Meter
send: 9-9-0-0 s=255,c=3,t=12,pt=0,l=3,st=fail:1.0
send: 9-9-0-0 s=1,c=0,t=13,pt=0,l=3,st=fail:1.4
lost parent
find parent
send: 9-9-255-255 s=255,c=3,t=7,pt=0,l=0,st=bc:
read: 0-0-9 s=255,c=3,t=8,pt=1,l=1:0
new parent=0, d=1
send: 0-9-0-9 s=255,c=3,t=8,pt=1,l=1,st=fail:0
read: 0-0-9 s=255,c=3,t=8,pt=1,l=1:0
send: 9-9-0-0 s=1,c=2,t=24,pt=1,l=1,st=fail:0
send: 9-9-0-0 s=1,c=2,t=24,pt=1,l=1,st=fail:0
send: 9-9-0-0 s=1,c=2,t=24,pt=1,l=1,st=fail:0
send: 9-9-0-0 s=1,c=2,t=24,pt=1,l=1,st=fail:0
lost parent
find parent
send: 9-9-255-255 s=255,c=3,t=7,pt=0,l=0,st=bc:
read: 0-0-9 s=255,c=3,t=8,pt=1,l=1:0
new parent=0, d=1
...

Partial gateway log:

MyMQTT/9/1/24
>>30 10 00 0D 4D 79 4D 51 54 54 2F 39 2F 31 2F 32 34 30 
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=1,l=1:0
MyMQTT/9/1/24
>>30 10 00 0D 4D 79 4D 51 54 54 2F 39 2F 31 2F 32 34 30 
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=1,l=1:0
MyMQTT/9/1/24
>>30 10 00 0D 4D 79 4D 51 54 54 2F 39 2F 31 2F 32 34 30 
<<C0 00 
>>D0 00 
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=1,l=1:0
MyMQTT/9/1/24
>>30 10 00 0D 4D 79 4D 51 54 54 2F 39 2F 31 2F 32 34 30 
0;0;3;0;9;read: 9-9-255 s=255,c=3,t=7,pt=0,l=0:
0;0;3;0;9;send: 0-0-9-9 s=255,c=3,t=8,pt=1,l=1,st=fail:0
0;0;3;0;9;read: 0-9-9 s=255,c=3,t=8,pt=1,l=1:0
0;0;3;0;9;send: 0-0-9-9 s=255,c=3,t=8,pt=1,l=1,st=fail:0
....

Pulse Sensor code is default except for the hard coded id:
gw.begin(incomingMessage, 9, false, AUTO, RF24_PA_MAX, 76, RF24_250KBPS);

[hek]

Please use 1.4.1

[bjornhallberg]

@hek Thanks! That seems to have fixed the "lost parent" issue. But unfortunately I had to move to the development branch since I need MQTT_TRANSLATE_TYPES to get MyMQTT/9/1/24 instead of MyMQTT/9/1/V_VAR1 for a python script I have running pushing the data to Domoticz. I'll see if I can find a way around it,

Turns out I was running a September development branch before ...

Edit: The problem seems to persist with the current development branch?

[bjornhallberg]

Can't seem to get this sensor to work.

Is the LM393-based module from the store able to detect IR wavelengths? How should it be mounted? Photodiode horizontal or vertical with regard to the IR source? How precisely do you have to adjust it?

The sensor can't seem to detect anything for me. Adjustment either gives the detection LED on the module always on or always off. MQTT log gets filled up with for V_VAR1 (e.g MyMQTT/9/1/V_VAR1). Can I temporarily set this variable manually on the gateway and shut the sensor node up somehow while I troubleshoot the other stuff?

[bjornhallberg]

So, I re-positioned the LM393-module so the IR source hit the photodiode head-on and not from the side. The activity LED is now blinking. I think we have a winner.

[bjornhallberg]

Just keep getting MyMQTT/9/1/V_VAR1 though every SEND_FREQUENCY.

The gateway has this to say:

0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
MyMQTT/9/1/V_VAR1
>>30 13 00 11 4D 79 4D 51 54 54 2F 39 2F 31 2F 56 5F 56 41 52 31 
0;0;3;0;9;read: 9-9-255 s=255,c=3,t=7,pt=0,l=0:
0;0;3;0;9;send: 0-0-9-9 s=255,c=3,t=8,pt=1,l=1,st=ok:0
<<C0 00 
>>D0 00 
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
MyMQTT/9/1/V_VAR1
>>30 13 00 11 4D 79 4D 51 54 54 2F 39 2F 31 2F 56 5F 56 41 52 31 
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
MyMQTT/9/1/V_VAR1
>>30 13 00 11 4D 79 4D 51 54 54 2F 39 2F 31 2F 56 5F 56 41 52 31

The MQTT log is also pretty monotonous. Except for when you restart the node, it briefly claims that VAR1 equals 1.4.1, Duh.

2014-11-07 08:42:41.992706 | MyMQTT/9/1/V_VAR1 
2014-11-07 08:43:02.044188 | MyMQTT/9/1/V_VAR1 
2014-11-07 08:43:27.568491 | MyMQTT/9/1/V_VAR1 1.4.1
2014-11-07 08:43:47.664348 | MyMQTT/9/1/V_VAR1 1.4.1
2014-11-07 08:44:07.722251 | MyMQTT/9/1/V_VAR1 
2014-11-07 08:44:27.775835 | MyMQTT/9/1/V_VAR1 
2014-11-07 08:45:07.891259 | MyMQTT/9/1/V_VAR1 
2014-11-07 08:45:27.959951 | MyMQTT/9/1/V_VAR1 

@hek Any idea how to move forward? I don't understand how VAR1...VAR5 quite work or why it can't be fetched or set. Is it a communication problem between sensor and gateway? Or something do to with the MQTT gateway? Or have I messed something up here?

---

Also I'm sort of wondering, how KWH are reported over time. It seems the value is incremented endlessly within the code. But for Domoticz I'd have to send only the accumulated kwh for that day if I understand things correctly, so basically I'd have to reset the value somehow or factor in the old count at the start of every day. Is is possible to overwrite VAR1 and reset the sensor remotely? Otherwise, resetting a variable in my python mqtt script at midnight might work better. Programming is not really my thing. I'd have to give this some thought. Perhaps I'd be worth the time to implement the RTC module and have the node reset the value itself at midnight?

Data is sent to Domoticz as follows, but ENERGY is only a "dummy" counter as they put it so every time you send a value you'd have to do the math yourself. These controllers are killing me ...

/json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=POWER;ENERGY

[hek]

I'm not running the MQTT client myself.. but it looks weird that payload is 1.4.1.
Just to double check.. You're running 1.4.1 on both sensor and gateway now?

@Damme
Does requesting of variables work through MQTT at all?

[bjornhallberg]

@hek It should be 1.4.1 on both, unless I made some horrible mistake with the sensor before installing it yesterday. I did flip between the development branch and stable 1.4.1 a few times but in the end I found the development branch wonky.

[bjornhallberg]

@hek I flashed the ethernet gateway instead and pretty much the same came up in the log:

0;0;3;0;14;Gateway startup complete.
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
9;1;2;0;24;
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
9;1;2;0;24;
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
9;1;2;0;24;
0;0;3;0;9;read: 9-9-255 s=255,c=3,t=7,pt=0,l=0:
0;0;3;0;9;send: 0-0-9-9 s=255,c=3,t=8,pt=1,l=1,st=ok:0
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
9;1;2;0;24;
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
9;1;2;0;24;
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
9;1;2;0;24;
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
9;1;2;0;24;
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
9;1;2;0;24;
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
9;1;2;0;24;
0;0;3;0;9;read: 9-9-255 s=255,c=3,t=7,pt=0,l=0:
0;0;3;0;9;send: 0-0-9-9 s=255,c=3,t=8,pt=1,l=1,st=ok:0
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
9;1;2;0;24;
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
9;1;2;0;24;
0;0;3;0;9;read: 9-9-0 s=1,c=2,t=24,pt=0,l=0:
9;1;2;0;24;

I changed the pins in the code and ran the serial gateway as well. Same basic log.

Could it be that data isn't reaching the sensor node? Cause I just soldered up a NRF24+PA+LNA and its own AMS1117 so that would be surprising. Reception at least has given me no problems and I'd think that transmission would be phenomenal (even stepped RF24_PA_LEVEL_GW to max). The sensor node also has a 3m+ extension cable (3x0.75mm2 wire) to its photodiode sensor just so the radio will be clear of any transmission problems (which would otherwise consist of thick walls+corrugated metal). It must have had a couple of hundred attempts by now to send VAR1. Perhaps I should take my own advice and attach a capacitor to the gateway NRF24. I've started using 1206 10uF ceramic caps (easy to solder since they are about as long as the DIP width) on sensor nodes and that seemed to have no ill effects at the very least.

[hek]

@bjornhallberg

I can't see any transmission errors.

If we back a bit. What exactly is not working? What controller are you using? The meter sketch fetches VAR1 at startup through a request-message (REQ). The request messages must be replied to on the controller side. Which controller didi you use and does it really implement the reply-to-REQ-functionality?

[bjornhallberg]

@hek The MAIN problem is that the sensor node (9) is not receiving VAR1 so it never actually starts transmitting any watt and kwh.

I use Domoticz as a controller, though controller may not be the right word since it is only one-way communication for storing sensor data via a Python script that I cobbled together to take MQTT readings and transmit them to Domoticz JSON.

I got the impression that VAR1 etc are stored in the gateway only. If not then I clearly have a very obvious problem.

Any ideas on how to code this to communicate with the MQTT gateway via code? I already tried to publish "MyMQTT/9/1/V_VAR1" with a payload to the MQTT Gateway but that didn't seem to work.

[hek]

Nothing gets stored in the gateway except routing information. The controller (or in your case python script) must answer the REQ command with a SET command containing the payload the node is interested in.

[bjornhallberg]

@hek Ok, I feel pretty stupid right now.

Looking at MyMQTT.cpp you'd think that communicating with sensors would just be a matter of sending "MyMQTT/9/1/V_VAR1" "12345" and it gets picked up and sent via sendRoute but it doesn't seem to work.

<<30 19 00 12 4D 79 4D 51 54 54 2F 39 2F 31 2F 56 5F 56 41 52 31 0D 31 32 33 34 35 
0;0;3;0;9;send: 0-0-9-9 s=1,c=1,t=63,pt=0,l=5,st=fail:12345

Perhaps I should change the sensor code for the time being so it doesn't request any data or stops after a few attempts and starts at zero. Watt reading is a lot more important than kwh right now at any rate.

[bjornhallberg]

I think this is officially sort of solved now.

Changed the sensor code so it only asks for VAR1 four times, then starts doing its job. Sure there are other implications but I was just too impatient.

Still a lot of unknowns in this equation, but at least to my surprise, Domoticz did have some sort of intelligence built-in and seems to automatically start with a fresh counter every day. I was worried I'd have to schedule something in Python to store and subtract "old kwh". Though this makes it even more pressing that I get communication between the gateway and sensor working so I can send back the pulseCount after a reset or some such.