@amitach said:

Hi,

I have a mqtt gateway running on arduino from mysensors library. I also have an openhab controller running on a raspberry pi connected to the arduino uno through the ethernet shield. I am trying to create my first item on openhab and I understand that the format required is
MyMQTT/20/0/V_TEMP where 20 and 0 are node id and sensor id respectively.

I can see following message on the serial monitor

Started!
0;0;3;0;9;read: 20-20-0 s=1,c=1,t=16,pt=0,l=1:1

1. How do I configure the node id and the sensor id?
2. Is it assigned automatically or do I assign it statically?
3. How do I understand the above output on the serial monitor?

You can let the gateway autoassign node IDs or take it in your own hands.

What I found useful is to not rely on the automatic assignment but give my nodes a static ID, you can do that by replacing the gw.begin function call by this:

gw.begin(NULL, NODE_ID, false);

where NODE_ID is your chosen ID (you can use "#define NODE_ID 12" for example to specify it before).

The sensor ID is specified by you. So in each example you see a line something like this:

MyMessage msgMotion(CHILD_ID_MOTION, V_TRIPPED);

where the first argument (here CHILD_ID_MOTION) specifies the sensor ID that will be sent along your message. You can, again, use #define to define a number in the top of your sketch.

The serial output was a mystery to me as well until I looked up the printout in the libraries/MySensors/MySensors.cpp file. It's constructed like this:

debug(PSTR("read: %d-%d-%d s=%d,c=%d,t=%d,pt=%d,l=%d:%s\n"),
			msg.sender, msg.last, msg.destination,  msg.sensor, mGetCommand(msg), msg.type, mGetPayloadType(msg), mGetLength(msg), msg.getString(convBuf)); 

So it's the sender's node ID, then probably the next hop's node ID, then the destination's node ID, then s=sensor ID, command type?, the message type (like V_TRIPPED, but as a number), payload type, length of the message, the message itself.

@hek Can you update the website for the decoupling capacitor recommendation? I wasted a lot of time trying to figure out why I have a lot of lost ACKs with my voltage boosted sensor until I found this topic. This made the sensors cry for a new parent quite frequently and it kept them awake more than necessary.

I had about 35% ACK packet loss with the 4.7uF capacitor which went down to 0.5% with a 68uF one (though the data got through). I will try to buy an even bigger low ESR one to make it zero, but the 4.7uF definitely doesn't do a good job if the signal is actually dirty.

@therik Yeah, now that I've read through your "Efficiency of Voltage Boosters" topic, I understand things a little better, and I really have no clue why removing the caps made the PIR more stable. BUT your topic helped me solve my packet loss/acks not arriving problem by adding a bigger capacitor to my radio, so what I want to say is that you're awesome, thanks!

So, I'm quite a rookie when it comes to electronics, but I made the 3.3V modification to this PIR sensor too. I had trouble with stability as well when I removed the voltage regulator and the diode, so I removed the two capacitors from the bottom (one 47uF, and the other 22uF) that I assumed are the buffers on both sides of the voltage regulator. Now the sensor is fed directly from my 3.3V step-up converter (based on NCP1402SN33T1) and it's very reliable and stable.

I have 2 of these sensors connected to the two interrupt pins and my sensor is going strong since 2 weeks on a single AAA NiMH battery (750mAh). I think it has at least another 2 weeks in it.

I'm using these to trigger the lights in my entrance room, so I'd notice if they wouldn't work. The board also wakes up every minute to send the battery voltage and I don't see unusual wakeups or unresponsiveness.

@amitach said:

Hi,

I have a mqtt gateway running on arduino from mysensors library. I also have an openhab controller running on a raspberry pi connected to the arduino uno through the ethernet shield. I am trying to create my first item on openhab and I understand that the format required is
MyMQTT/20/0/V_TEMP where 20 and 0 are node id and sensor id respectively.

I can see following message on the serial monitor

Started!
0;0;3;0;9;read: 20-20-0 s=1,c=1,t=16,pt=0,l=1:1

1. How do I configure the node id and the sensor id?
2. Is it assigned automatically or do I assign it statically?
3. How do I understand the above output on the serial monitor?

You can let the gateway autoassign node IDs or take it in your own hands.

What I found useful is to not rely on the automatic assignment but give my nodes a static ID, you can do that by replacing the gw.begin function call by this:

gw.begin(NULL, NODE_ID, false);

where NODE_ID is your chosen ID (you can use "#define NODE_ID 12" for example to specify it before).

The sensor ID is specified by you. So in each example you see a line something like this:

MyMessage msgMotion(CHILD_ID_MOTION, V_TRIPPED);

where the first argument (here CHILD_ID_MOTION) specifies the sensor ID that will be sent along your message. You can, again, use #define to define a number in the top of your sketch.

The serial output was a mystery to me as well until I looked up the printout in the libraries/MySensors/MySensors.cpp file. It's constructed like this:

debug(PSTR("read: %d-%d-%d s=%d,c=%d,t=%d,pt=%d,l=%d:%s\n"),
			msg.sender, msg.last, msg.destination,  msg.sensor, mGetCommand(msg), msg.type, mGetPayloadType(msg), mGetLength(msg), msg.getString(convBuf)); 

So it's the sender's node ID, then probably the next hop's node ID, then the destination's node ID, then s=sensor ID, command type?, the message type (like V_TRIPPED, but as a number), payload type, length of the message, the message itself.

@AWI said:

Seriously... what is the added value of having the radio connected directly to the Pi instead of using an Arduino (serial) gateway. Taking into account:

• The arduino is very stable: timing wise (it is only processing radio messages). The Pi can be very busy with all sorts of things and therefor easily miss messages.

I think if the Raspberry is too busy to process messages it will be too busy to process them after the Arduino sends them. Also looking forward the new Pi 2 is actually ~6 times more powerful with 4 cores.

• The arduino should not cost you more than a few bucks and has a simple and reliable radio and serial interface.

It needs an extra power supply, an extra ethernet cable + one more port on my router, consumes about the same space as a Pi (at least an Uno). And while it's reliable, I already have to rely on the Pi's reliability to run my automation anyway.

• the Gateway gets you started with the MySensors concept (including debugging via serial).

The controller is still rather a black box for me because of all the magical translations between RF24 packets and MQTT messages. It also required some SoftSPI thing that was very confusing for me, different wiring than the sensors. I'd say it's the weakest point in the simplicity of the whole mysensors project.

Also every time I try to connect to the MQTT server Arduino with an MQTT client to debug, it breaks the connection to my openHAB (seems it can only handle 1 client?).

• (personal) I rather have programming fun with the sensors i.s.o.. spending long hours on getting buggy solutions. but hey everybody needs his own challenge..

I keep my current gateway node as well, I don't think I'll find the way to make this work, because I'm not as good in this system, but I would assume that Pi+openHAB as the brain is a common use case, and for that an extra Gateway is not giving any value. But I guess it's not too wise from my part to argue with it when the code doesn't exist.

@ericvdb said:

I'm talking about a MySensors Ethernet Gateway running on the Pi instead of an Arduino.

+1 I'm amazed nobody put this together yet. It's absolutely useless to have a gateway when we can easily hook up an NRF24L01 to the Raspberry and use it as the gateway/mqtt publisher. There's even the RF24 library for the Pi.

I was afraid that this was done before and I'm reinventing the wheel, but it seems I should actually get to it and hack something together. So many pieces are there.