adafruit / Wippersnapper_Protobuf

Protocol buffer messages for Adafruit.io WipperSnapper Beta
MIT License
0 stars 2 forks source link

Add registration complete message #66

Closed brentru closed 3 years ago

brentru commented 3 years ago

MQTT can not guarantee the order of messages. It's possible that the registration response has to re-transmit, but the component configuration message is delivered.

This causes a device to never configure its components:

15:18:26.984 -> Polling for registration message response...2
WRONG MESSAGE
15:18:26.984 -> cbSignalTopic: New Msg on Signal Topic
15:18:26.984 -> 12 bytes.
15:18:26.984 -> decodeSignalMsg
15:18:26.984 -> cbSignalMsg
15:18:26.984 -> Sub-messages found: 1
15:18:26.984 -> Signal Msg Tag: Pin Event
15:18:26.984 -> cbDecodePinEventMsg
15:18:26.984 -> Digital Pin Event: Set 37 to 1
CORRECT MESSAGE
15:18:26.984 -> GOT Registration Response Message:
15:18:26.984 -> Hardware Response Msg:
15:18:26.984 ->     GPIO Pins: 17
15:18:26.984 ->     Analog Pins: 4
15:18:26.984 ->     Reference voltage: 2.60v
15:18:37.642 -> Registered board with Wippersnapper.
15:18:37.642 -> PING!

This pull request proposes RegistrationComplete, a message sent from the device to Adafruit IO after the device configures its component. It signals to the broker that its ready to receive configuration messages.

brentru commented 3 years ago

@lorennorman - another issue - do we also need to "lock" the configuration messages? What happens if a pin event arrives after a pin request? Due to the same retransmission issue.

lorennorman commented 3 years ago

I see your point with the configuration messages, I send all the configs one after another, and then I send all the "last_value"s one after another, but this would seem to be susceptible to the same ordering issue if a config message had a miss and its last_value counterpart hit first...

This is crazymaking. But another simple even for ConfigurationComplete or whatever wouldn't be too bad, then I could split that part up as well.