Unexpected error (intermittent) unpacking a DeviceNotification message from the hub

[skezell]

I am using the python example to build a command line utility that will download and run my python program without using the spike app (thus allowing me to setup a run config in IDE and edit there).

In running the example, it mostly works except that after the program runs I get an error in struct.unpack complaining that the buffer is not the correct size.

2024-12-28 10:59:03 [INFO ]: Received: ProgramFlowNotification(stop=True)
2024-12-28 10:59:05 [ERROR ]: unexpected error:<class 'struct.error'>:unpack requires a buffer of 2 bytes
2024-12-28 10:59:10 [ERROR ]: unexpected error:<class 'struct.error'>:unpack requires a buffer of 2 bytes
2024-12-28 10:59:15 [ERROR ]: unexpected error:<class 'struct.error'>:unpack requires a buffer of 2 bytes
2024-12-28 10:59:20 [ERROR ]: unexpected error:<class 'struct.error'>:unpack requires a buffer of 2 bytes

In this snippet from my log, the first line is the completion of the python example program. Then the error will continue to log until I disconnect from the hub.

Digging into it a bit more, I discovered that it is only the DeviceNotification message coming from the hub that ever raises this error. I started putting some print statements to figure out what was going on and at some point, it started working (meaning no error and it would print data status data from the hub). Based on this, I'm guessing that it's some sort of timing issue? Like maybe it's not waiting long enough for the entire message or something similar? Dunno. But works sometimes and not others and I don't really know how to figure out why.

When the message deserializes without error, it looks roughly like this.

2024-12-28 10:57:55 [INFO ]: Received: DeviceNotification(['5x5', 'IMU', 'Battery', 'Motor', 'Motor', 'Motor', 'Color'])
2024-12-28 10:57:55 [INFO ]: - Battery : (0, 100)

• IMU : (1, 0, 0, 2, 5, -4, -8, -6, 965, 0, 0, 0)
• 5x5 : (2, 0, 100, 100, 100, 0, 0, 0, 0, 100, 0, 0, 100, 100, 100, 0, 0, 100, 0, 0, 0, 0, 100, 100, 100, 0)
• Motor : (10, 0, 48, 176, 0, 0, 176)
• Motor : (10, 1, 48, -65, 0, 0, -65)
• Motor : (10, 2, 49, -92, 0, 0, -92)
• Color : (12, 4, 10, 65379, 3, 4)

For my purposes right now, I can simply ignore this particular message type, but would eventually like to be able to print status as long as the hub is still connected. Once I am running more complex programs on the hub, the status information would be very useful. Any thoughts, ideas, etc. to investigate and get this part working would be most helpful.

System versions, in case it matters.
OS X - Sequoia v. 15.2
Hub OS v. 1.6.62
Here is the output from the InfoResponse message, which seems to have an RPC version # as well?
2024-12-28 10:57:30 [INFO ]: Sending: InfoRequest() 2024-12-28 10:57:30 [INFO ]: Received: InfoResponse(rpc_major=1, rpc_minor=0, rpc_build=14, firmware_major=1, firmware_minor=6, firmware_build=62, max_packet_size=182, max_message_size=5000, max_chunk_size=4096, product_group_device=0)

[SteffenLEGO]

I am relatively certain I have seen this issue as well when using the python experience in the spike app.

If it is indeed the same issue, then this is a bug we have, that will be fixed in the next release that includes a firmware update, but I unfortunately have no information about when such an update will be available.

I believe you can get around the issue by slowing down your communication a little, I think the biggest offenders in this is usually the python print and the tunnel messages, where you can pretty easily get the hub to try and send data faster than what is possible with the connection, which I think is ultimately what is causing the issue.

[skezell]

I sort of figured out what was going. For some reason, the Battery message includes an extra zero byte. when I changed the format to take one more byte for that message, then everything lines up and the whole message decodes correctly. I'll add a PR soon for the change (still testing), but not sure that you'd want to merge it? I believe that this is a bug for spike - either the hub is sending the incorrect number of bytes OR the documentation for that message is incorrect. Once it's determined which it is, then you can decide what to do.

[SteffenLEGO]

That is a very interesting find.
Could you provide your code, so I can have a look and see if I can reproduce?