Tutorial 05 of 05

When it breaks.

Follow one broken message from the device to the reject hint and fix it yourself.

Success looks likeThe deliberate reject appears, then the corrected message is accepted.

You will break one message on purpose. The backbone will keep it, name the mistake, and show the exact fix. Learn this path before you need it.

Read the page in this order

  1. Find the device state. never seen means the broker has received nothing. alive means the network path works, even if a value is wrong.

    done when: you can say whether this is a connection problem or a message problem.

  2. Watch the live raw tail. A good message appears here immediately. The exact topic tells you which device and measurement arrived.

    done when: you see your device ID in a new row.

  3. Open the reject feed. Read the bold hint before reading the raw payload. It is written to tell you what to change.

    done when: you can name the wrong field and the accepted value.

  4. Fix one argument and publish again. Do not change the measurement or value while testing the unit fix.

    done when: a good row arrives and the device stays alive.

Make a deliberate reject

Add this line once inside the one-minute block. It deliberately uses the wrong unit:

spine.publish("temperature", 23.4, "C");

The helper still builds a complete canonical message. The validator rejects it because C is not the registered unit.

After the reject appears, correct only the final word:

spine.publish("temperature", 23.4, "celsius");

Publish once. The reject feed must show this exact teaching hint:

Expected reject

unit_mismatch

You sent unit: “C” but temperature expects celsius. Units are spelled out.

The broken message is not discarded. It is stored in the reject feed with its topic and the full message built by GardenSpine.h. Publish the corrected line once, then remove the fixed-value test line and return to your sensor readings.

Expected recovery

A new reading appears in the live raw tail. The rejected message stays visible as a record of what happened.

What each panel answers

Panel Question it answers
Device state Has the backbone heard this device recently?
Latest values What did the last accepted message contain?
Reject feed Why was a message refused, and what field should change?
Live raw tail Did the message I just sent arrive?
Connection log Did MQTT connect, and what did the device subscribe to?

If the hint is not enough

Open the full troubleshooting guide and find the reject reason. Change one argument at a time. The helper keeps device ID, timestamp, firmware version, topic, and JSON formatting consistent.