Troubleshooting

@DavidZH hi. Really ? I will test it . thank you

@ikkeT, I've used the PIN 3 with a door sensor, it work perfectly, just enable the mode INPUT_PULLUP on the setup. void setup() { pinMode(DOOR_PIN, INPUT_PULLUP);

could be, if you have a MB102 you can try with that; I also read someone suggesting to have a resistor from the PIR digital pin to GND, but I haven't tried it

@bobbybobbybobby @pansen and @tbowmo fimaly i got arduino ide running on my rpi!!! i was trying this for about a weeks now. thanks for the support.

@Boots33 I have a 10 pin nrf but the wiring is the same. It works now. That linechange did the trick! Janos

Thank you friends :pray:

The problem is avr-g++: error: CreateProcess: No such file or directory Without any code we won't be able to help. It looks like a header is missing.

I think I found it. if (interval<10000L) { // Sometimes we get interrupt on RISING return; } It seems to be that my interrupt is to quick. above code is default if I change to if (interval<35000L) { // Sometimes we get interrupt on RISING return; } it will calculate Watt as I think it should be. I will let it run for a week and see if kWh is OK now.

@anvil - great code sleuthing! I have been absent due to travel but to ensure this doesn't slip through the cracks and create future confusion for other users, I have filed GitHub issue https://github.com/mysensors/MySensors/issues/770 to add these defaults into the RPI gateway example for the 2.2.0 release. With your increased familiarity with the code base, feel free to make the change and submit a GitHub PR if you are so inclined, otherwise it will wait until one of the core members makes the change.

Thanks! I resolved it last night... the problem turned out to be on the gateway side, I think. I disconnected and reconnected all of the wires and when it came back up, the debug log showed signs that they were talking. :) You are correct, the MY_NODE_ID line was too far down in the code... I made a lucky guess and moved it up higher and then it started working. Thanks for your help!!

When i limit the lenght with send(nikoBusMessage.setSensor(SIMULATIE_LCD_ADRES).set(payload,8)); I get this as output (ascci values of char) : 0;54;1;0;47;3132333435363738 Maybe a bug in library? But indeed the solution with the nul character works fine. Than

Yes. Correct. call BME.begin() every time and the subroutine only at the beginning. And you are also correct about the library. I use the "blue" lib, from Sparkfun. As i can recall correct (it's been over a year since I built the damn thing) I have tried both, and found the Sparkfun more stable. And you CAN switch off power for this module, but after conversion it goes to sleep and uses less than 1uA. Hardly worth the effort, because the current can find a way over the data lines, and that's a pain in the behind to solve (I tried!).

Update: Managed to get my NFR24 radios work with Sensebender micro with greatly oversized 100uF normal electrolytic capacitor. Been in my freezer (appr. -20C) now for three days and still works fine. 2xAA batteries powering the node. Not sure where the problem is, maybe just the capacitor size because of diminishing capacitance curve in freezing temperatures. Have still some spare Nanos and Pros to spend, but gradually moving to ESP8266 based sensor network. They have proven to be very reliable even under -20 degrees celsius.

@pansen This is more a guess, but I think the real one (GPIO) is only for the interface between radio and serial gateway program. The virtual is for the interface between serial gateway program and controller. Serial interfaces are exclusive to one program at a time. Someone should verify what I just said though.

@mfalkvidd: I just finished version 2 of a prototype, when It is working like I want I will present it in the "Projects" subforum :+1:

@MLs Signing is supported using both atsha204a and pure software. They are perfectly compatible so you can mix all you want. What is important to understand is that if you use software based signing, if someone gets physical access to your node, they can dump eeprom and obtain your secret hmac key (PSK) and using that they can potentially compromise your node network. The benefit of a atsha is that the key is securely stored and cannot be extracted from the chip. At least it is according to Atmel. So if you plan to put your node "outside" it is recommended to use atsha. On your gateway it is less important as you would typically have your gateway placed "securely". If you do not, then your network would be compromised as an attacker could tap in to the communication between gateway and controller, which is not secured. This limitation is not accidental. Supporting security between gateway and controller mean a dependency which would limit the ability to support a wide range of controllers and is therefore undesirable. And personally I don't really see a usecase for it anyway as gateways generally are placed indoors and are hooked up to a LAN in one way or another.

i am testing this on 4 model of controller ! ( 2 raspberry - 1orangepi -1 laptop) i test with same arduino same wire same max485 module and same sketch and same usb serial cable

Hello, I think I have found the error. I use a 15sec. loop in the sketch and i thing a intern watchdog reset the Node. regards Thomas

[image: 1486109459443-lightreading-resized.jpg] Miles away... When my reading in BH1750.h library is at 529 lux My reading in MySensors is at 34-39 lux So I'm not sure why.... I'm guessing maybe it's the resolution mode in MySensors? Here's my serial print. Please disregard the Buf label, its just my sloppy labelling. :) [image: 1486109791738-lightreading-com.jpg]