Development

@y4CdW42Ol8 said: What can i use to create an interrupt to wake a sleeping Arduino? This using your Plant_Moisture_Sensor sketch. A timer (whick my sketch alreay uses) or a change in an interrupt pin, see the Sleeping section on https://www.mysensors.org/download/sensor_api_15#the-full-api and http://playground.arduino.cc/Code/Interrupts

@parachutesj thank you very much. looks good now.

@Koresh Intresting option: to generate a full reset if no sign of life for ... time limit. I would implement this without special library/ MySensors functionality. Just use gw.sleep( xx ms) ; and generate a pulse every xx ms in the main loop.

@stranger @Anticimex Fixed in PR#503

@GertSanders I think there is a better chance that the controller is going to be online. I have a mini UPS on my RPi for example if there are no mains supply. I also have a device pinging the controller and if it is not responding sending the halt/reboot signal to the RPi. If your node is working an a universal GSM gateway, that's a different story though. But does it have a power (battery) backup in case there is a blackout ?

What payload do you send in the message? Each scene controller can have multiple buttons. Example: MyMessage msg1(CHILD_ID_3,V_SCENE_ON); MyMessage msg2(CHILD_ID_3,V_SCENE_OFF); send(msg1.set(1)); // Turn on scene button 1 send(msg2.set(1)); // Turn off scene button 1 send(msg1.set(2)); // Turn on scene button 2 send(msg2.set(2)); // Turn off scene button 2

@TheoL said: I would strip the complete sketch and leave only the button part in it. That way it's much easier to detect if there's any mistake. It's really hard to help you with a sketch if this size. You could try to give the debouncer a higher interval, e.g.: debouncer2.interval(25); Thanks for the troubleshooting tip! @mfalkvidd After commenting out almost all of the LCD/temp functions i was left with the last wait that caused the problems, it seems to be working now but havent got the time to run it more than a few minutes.

@scalz I manage to narrow it down only to "drivers/ATSHA204" compile issues, which is signing.

@sundberg84 yes, but there is no guarantee that both nodes receive the message (due to the low level ACK mechanism)

@Dick Not sure what your approach is but normally i start with prototyping using these wires and when all works fine (software and hardware) i solder everything together on a PCB.

@NickBuilder said: Thank you @mfalkvidd for the very educational description. I thought that the check could have been as you described but I felt that it was too crude and simple. This doesn't seem to be the most typical use of "exclusive or" but I guess it does the job. There are more advanced ways. This scheme will not detect two bit errors in the same group (even or odd) and it can only detect errors, not correct them. But without knowing the reasoning behind the design it is impossible to say if it was a bad choice or not. Is it common to only include part of the transmission packet in the parity check? I would have assumed that the nib (Nib4) should be part of the bit check and that the parity bits would then be set or not set so that the complete packet is confirmed. Yes, it is common to exclude things. What things depends on the use case. From what I understand, the exact same message is always sent three times. If the z-bits were included in the checksum, a new checksum would have to be calculated for each time the message is sent. That would probably have a negative effect on the communication speed and would add complexity to the solution without adding any real benefit. If the checksum bits themselves (C) were included in the checksum calculation they would affect the checksum so the checksum would change so the checksum would have to be calculated again which would cause the checksum to change so the checksum would have to be calculated again and so on.

Thanks! The looks alot like what I did with my non-mysensors stuff. So that is perfect!!

I don't seem to be getting any replies here, so I'm moving to github here: https://github.com/mysensors/Arduino/issues/480

@badmannen I am on to it:)

@BartE Ok, I think I got it all. Great tnx a lot

@NeverDie Yes, you are correct - it is based on ATMega1284P. So not relevant My point is that I'd rather stick to the datasheet rather than overclock, but that's just me. And yes I realise that Moteino is overclocking, but the size, voltage and flash are really appealing to me.

This is still in an alpha state and ESP8266 development may take some time. This is a TFT screen with the daughter board: [image: 1466201112943-image.jpg]