Troubleshooting

@MarcoE I think I do have units with the issue, my hope was you could share it here for all to see, it might help solve a number of issues for the community...

@Mark-Swift Almost :) #define MY_TRANSPORT_WAIT_READY_MS 60000 applies only when the node starts, i.e. before entering loop(). Once you are in loop() and you put the node to sleep #define MY_SLEEP_TRANSPORT_RECONNECT_TIMEOUT_MS 10000 defines how long the node will try to establish a connection before going to sleep, default is 10s. Please have a look here for additional information.

I think i solved it by replacing the tripped code with this modificed code from https://codebender.cc/example/MySensor/BinarySwitchSleepSensor#BinarySwitchSleepSensor.ino { uint8_t value; static uint8_t sentValue=2; // Short delay to allow buttons to properly settle sleep(5); value = digitalRead(BUTTON_PIN); if (value != sentValue) { // Value has changed from last transmission, send the updated value send(msg.set(value==HIGH ? 1 : 0)); sentValue = value; }

@robosensor I have tried the bool in the present() function but it doesn't help setting it to true...

@Efflon Hi, in fact radio modules with blob where the problems as I got them replaced with IC ones.

Support for atmega168 has been added in the development version of MySensors and will be available in the next stable release. More info in https://forum.mysensors.org/topic/5727/compile-error-for-pro-mini-5-5v-168/

Support for atmega168 has been added in the development version of MySensors. More information: https://forum.mysensors.org/topic/5727/compile-error-for-pro-mini-5-5v-168/8 However, note that due to the small flash size of the atmega168, quite few sketches will fit.

Ahhh.. That worked!!! Thank you very much!!!

Adding a capacitor at the radio solved my issues... Sorry for not trying that from the very beginning, today I bought some capacitors, and now it looks good! Happy now! 33804 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:24.0 33818 TSF:MSG:SEND,3-3-0-0,s=2,c=1,t=1,pt=2,l=2,sg=0,ft=0,st=OK:62 34127 MCO:SLP:MS=60000,SMS=0,I1=255,M1=255,I2=255,M2=255 34134 MCO:SLP:TPD 34136 MCO:SLP:WUP=-1 Sending initial value 34154 TSF:MSG:SEND,3-3-0-0,s=1,c=1,t=0,pt=2,l=2,sg=0,ft=0,st=OK:1 Requesting initial value from controller 34164 TSF:MSG:SEND,3-3-0-0,s=1,c=2,t=2,pt=0,l=0,sg=0,ft=0,st=OK: TempDiff :1.01 HumDiff :1.50 T: 23.00 H: 65

@ohuf Learned something new. Until now I even didn't know that boards.txt was available at GITHUB. I think replacing boards.txt twice might be redundant, but this is a pure guess. Important for now is: have much fun with your new functional Gateway!

Hmm strange, could it be due to receiving something else that you remote? I assume the 433MHz receiver is receiving anything it can pick up

Ok sorry, I see the difference. I still use version 1.5.4

@MLs Since not gateway talked to the controller so the node is not passed on to DHT. But the problem with Domoticz and MQTT I still have. Can not get the Domoticz to redeem from MQTT. //Mattias

Thanks Yveaux, This led to a whole new range over errors : call of overloaded 'set(float)' is ambiguous I resolved the issue by changing the send command from : send(Phase1_Current.set(m_Phase1_Current)); to send(Phase2_Current.set((float)m_Phase2_Current,1)); Which is working fine now.

http://makezine.com/2016/03/08/beautiful-woman-soldering-stock-photo-wrong/