Strange behaviour - Check Wires and Version Mismatch

[hek]

What happens if you move the sensor close to the gateway while fetching id. When it has been received move sensor back to the final location.

I vaguely remember a discussion I had with @Yveaux where we concluded that the temporary id 255 would cause problems during initial id handover if a relay node was involved during this process.

The solution would be to choose some other id (254) during this handshake.

Just making a mental note from out discussion here:
"So a node takes on temp ID 254, broadcasts a parent-node request and selects the best incoming parent by distance (all sent to 254). Then it requests (still with ID 254) its node ID, which is forwarded to the gateway and each relay stores the route to 254 in its routing table. The gateway assigns one, and routes it back to 254, which then takes on its new node ID. Sounds good!"

[marceltrapman]

@hek Apologies for the late reply.
I have walked around with the sensor but without any luck.
The id is requested and the id is sent but that is it.
No further debug info either.
Attached is a screenshot of the arduino output (left) and the controller/gateway output (right).

[hek]

Hmm.. where did the id-payload (4) go?
Type should also be 4 (I_ID_RESPONSE) but it seems to be 3...

[marceltrapman]

@hek said:

Hmm.. where did the id-payload (4) go?
Type should also be 4 (I_ID_RESPONSE) but it seems to be 3...

Honestly I don't know what is happening here.
The controller seems to do its work well.
The gateway, as far as I can see, also.

The sensor is a black hole to me right now.

Below is the eeprom dump:

NODE_ID          :255
PARENT_NODE_ID   :2
DISTANCE         :2
ROUTES           :255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255
CONTROLLER_CONFIG:255255255255255255255255255255255255255255255255255255255255255255255255
FIRMWARE_TYPE    :255255
FIRMWARE_VERSION :255255
FIRMWARE_BLOCKS  :255255
FIRMWARE_CRC     :255255
LOCAL_CONFIG     :255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255255

Repeater id is indeed 2.
Don't know what the distance value represents.

[hek]

what happens if you hard-code parent to 0 in begin() while fetching id?

[marceltrapman]

@hek said:

what happens if you hard-code parent to 0 in begin() while fetching id?

Even stranger. This is what I do:

//board.begin(msgCallback, nodeId, repeaterMode, parentNodeId, paLevel, channel, dataRate);
board.begin(NULL, NULL, false, 0);

This is now the result:

NODE_ID          :0
PARENT_NODE_ID   :2
DISTANCE         :2

Do you want me to write the node id and parent id direct into the eeprom?

[hek]

setting the parent in constructor won't update the eeprom. It just uses the specified parent and never searches for a new one.

And you'll have to specify AUTO for id

[marceltrapman]

@hek So, how do I 'suddenly' have id = 0 then?

I will clear the eeprom again and see what happens...

[marceltrapman]

@marceltrapman Stupid fail with that AUTO setting :blush:

But the good news is that my sensor now has ID 4...

So the bad news, I guess, is that the repeater seems to fail...

[hek]

As I mentioned earlier fetching id THROUGH a repeater need some additional love.

[marceltrapman]

@hek said:

As I mentioned earlier fetching id THROUGH a repeater need some additional love.

Hmm, so I fail that love :(

How can we get this thing going?
The thing is don't want to walk down to my gateway each time I want to test something out.
And, I also prefer not to use a fixed id because that would make testing the controller plugin a b****.

[gregl]

Hey @marceltrapman - I just upgraded one of my sketches from 1.3 to 1.4 ( im finally moving to 1.4 in "production!!)

Anyway, i had the same issue with version mismatch error and spewing out

version mismatch
read: 255-255-255 s=255,c=7,t=255,pt=7,l=31:NAN
version mismatch
read: 255-255-255 s=255,c=7,t=255,pt=7,l=31:NAN
version mismatch
read: 255-255-255 s=255,c=7,t=255,pt=7,l=31:NAN
version mismatch
read: 255-255-255 s=255,c=7,t=255,pt=7,l=31:NAN

wondering wtf was going on, i disconnected the relays board connected to VCC... the messages stopped and everything worked correctly- other than the relays actuating...
figured it could be a power issue, i connected proper power source as the issue occured with just a USB 5v from my PC....and reconnecting relay all worked properly..including now the relay.

So, check your powersupply!

HTH..

[marceltrapman]

@gregl said:

So, check your powersupply!

I don't see the version mismatch thing anymore luckily but it would have surprised me if it was power. Not only did I check it but I also use a power converter in this case to supply constant 3.3v (I use pro mini 3.3v).

Anyway, thanks for the tip :)

[SparkAndHale]

Same here. I had to go up to 5V to power my Arduino Pro Mini 3.3V sufficiently.