ST=Fail = Add higher cap?

[sundberg84]

Hi!

I have a dallas temp sensor on a pro-mini 3.3v 8mhz.
Its powered with a booster and 2xAA.

Its been working great for 2 months but suddenly stopped working...
Battery is fine (also changed them just in case) and voltage on radio (also changed) and arudino is within limits.
Its not even working if i clear eeprom and upload scetch besides gateway.

Can it help adding a cap with higher uF (i have 4,7 today) or any other idea how I can debug?

Log:
sensor started, id 4
send: 4-4-255-0 s=255,c=0,t=17,pt=0,l=5,st=fail:1.4.1
send: 4-4-255-0 s=255,c=3,t=6,pt=1,l=1,st=fail:255
send: 4-4-255-0 s=255,c=3,t=11,pt=0,l=10,st=fail:Gillestuga
send: 4-4-255-0 s=255,c=3,t=12,pt=0,l=3,st=fail:1.1
send: 4-4-255-0 s=0,c=0,t=6,pt=0,l=5,st=fail:1.4.1
Temp: 28.80 C
send: 4-4-255-0 s=0,c=1,t=0,pt=7,l=5,st=fail:28.8
Battery percent: 83 %

Woaw its hot today - 22:00 and 29C in my livingroom...

[hek]

Something seems weird. The node has probably lost its parent.

It is trying to send to node 255.. Which is the broadcast address (that never uses hardware acks thus the fails..)

[sundberg84]

Why is that? And how do i fix it.
Can it be because i cleared eeprom and never got in touch with gw after that?

[hek]

Might be.. Try moving it closer to gateway.

[sundberg84]

I did, uploaded the scetch and started it in the same room as gw.
I also tried a 10uF cap.. no difference.

Must be some other hardware failure... well ill try to replace the pro mini.

[Sparkman]

@sundberg84 Do you have the ID hard coded? If not, it looks like the EEPROM did not clear properly as otherwise it would not have known it was sensor 4. Which EEPROM clearing method did you use?

Cheers
Al

[sundberg84]

@Sparkman I have ID hardcoded as ID 4.
I cleared it by uploading the scetch from MySes. lib. ClearEepromConfig

  for (int i=0;i<512;i++) {
    EEPROM.write(i, 0xff);

[Sparkman]

@sundberg84 This is just a guess on my part as I'm still learning the ins and outs of the MySensors protocol so @hek or someone else will need to confirm, but I think because you have the ID hard coded, the sensor does not go through it's normal discovery process and thinks the parent ID is 255 (ff) because of the EEPROM clearing routine. You could likely set the value at the address for the parent ID (I believe it's address 1) to 0 in the EEPROM (EEPROM.write(1, 0x0);) and it might start working again, barring any hardware issues. The other option is to remove the hard code for the ID, restart the node, and it should also start working again. Once it's working again, you can hard code it back to 4 after.

Cheers
Al

[A Former User]

@sundberg84 . please how is the hard coding done?

How do build the controller to assign id to the sensors?

[sundberg84]

@Sparkman Great tips - I will check tonight!

@odark007 I have not build a controller assigning ID, i code each sensor/node with a static Id pretty much as you choose between a DHCP adress or statis IP adress on your network device. If you want to choose id for your device change gw.begin (see the API for more info)

gw.begin(NULL, NodeID, true);
//incomingMessageCallback - Callback function for incoming messages from other nodes or controller and request responses. Default is NULL.
//nodeId - The unique id (1-254) for this sensor. Default is AUTO(255) which means sensor tries to fetch an id from controller.
//repeaterMode - Activate repeater mode. This node will forward messages to other nodes in the radio network. Make sure to call process() regularly. Default in false

[sundberg84]

@hek @Sparkman
Thank you for input.

I came home, change back to original radio and attached usb/serial debug with exact the same setup as last night - and everything worked!
A bit frustrating but I dont know what happened. I cant blame the hot day because it was in the celler with good temp when it quit...

Well, ill let it run and see what happens...