Telepathic Jar

Both jars run identical firmware. What differentiates them is two strings set through a web configuration portal on first boot: its own device ID and its partner's. Every MQTT topic is derived from those, so jar A publishes to telepathic_jar/JarA/data and subscribes to telepathic_jar/JarB/data, and the pairing is symmetric by construction rather than by configuration discipline. Adding a third jar would mean changing the topic scheme, not the code that reads sensors.

float temp  = bme.readTemperature();
float hum   = bme.readHumidity();
float light = lightMeter.readLightLevel();

mqttClient.publish(topic_publish_p2p_data.c_str(), output_json.c_str());
mqttClient.subscribe(topic_subscribe_p2p_data.c_str());

The system never shows a reading. Which colours the light is allowed to take, how bright it may get, and what makes the nebuliser fire are all authored decisions that map temperature, humidity, pressure, ambient light and live weather onto an atmosphere. Weather text from the API is matched to a base hue before temperature adjusts it, so rain and cold rain are related but distinguishable. The constraint that mattered was restraint: enough resolution to feel a change, not enough to invite reading it as a measurement.

The first firmware reconnected silently whenever the link dropped, which produced the worst possible ambiguity for a calm-technology object: a jar sitting quietly could mean it is calm where they are or the connection is gone. Those are opposite messages rendered identically. The shipped version adds periodic reconnection with explicit status reporting, so an unreachable partner looks different from a peaceful one. For a device whose whole point is being glanced at rather than read, an unreadable failure state is not a minor bug.