Interestingly, there’s the same bug showing up here as in the email I sent earlier (in Nolans thread). This is a bit of a nasty bug as it’s changing the received frames, although I don’t know that it’s causing any really major problems. The thing I couldn’t correlate when Iooked earlier is the following part -
2014-04-22 07:59:34 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:920]- Receive Message = 01 05 00 13 10 01 F8
2014-04-22 07:59:34 DEBUG o.o.b.z.i.p.SerialMessage[:216]- Assembled message buffer = 01 07 00 13 10 01 00 00 FA
2014-04-22 07:59:34 DEBUG o.o.b.z.i.p.ZWaveController[:142]- Message: class = SendData (0x13), type = Request (0x00), buffer = 01 07 00 13 10 01 00 00 FA
When we receive the message, it’s7 bytes long, but just a couple of log messages later, and it’s strangely mutated into 9 bytes! This is caused by the same bug as earlier, but it’s hidden in the depths of some seemingly harmless classes.
The offending line is -:
logger.debug(incomingMessage.toString());
which looks like this -:
public String toString() {
return String.format("Message: class = %s (0x%02X), type = %s (0x%02X), buffer = %s",
new Object[] { messageClass, messageClass.key, messageType, messageType.ordinal(),
SerialMessage.bb2hex(this.getMessageBuffer()) });
};
and it’s the getMessageBuffer call that’s causing the problem again. I’m slightly surprised I didn’t spot this earlier since I did a search on the uses of this call… Anyway, in this call one thing it does is -:
int messageLength = messagePayload.length +
(this.messageClass == SerialMessageClass.SendData &&
this.messageType == SerialMessageType.Request ? 5 : 3); // calculate and set length
This increases the size of the received packet by 2 bytes. Also, we again calculate the checksum, and perform a bunch more processing, so it’s wasting more of Nolans valuable RPi processor time :)
Since the message buffer gets dissected into its individual components, to print it out again, the binding has to totally recreate it (and it seems due to some assumptions, its not transparent, and we end up with these issues). I will change this so that after the frame has been received (and printed), we only print the payload - which is stored whole.
This will fix some issues (we won’t go and add some extra bytes to our received frames!), however, it probably isn’t the answer to your question of what the heck is screwing up the network on startup… I’ll take another look at that, and my previous email about the timeouts is the next mystery. For this, I’m less sure, but my previous comment about the timeout needs some investigation as I don’t understand the response there.
Let me fix this issue first (since I’ve largely worked it through) and then I’m happy to take a look at more logs to see if we can understand this some more :)
Cheers
Chris