social.coop is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Fediverse instance for people interested in cooperative and collective projects. If you are interested in joining our community, please apply at https://join.social.coop/registration-form.html.

Administered by:

Server stats:

488
active users

#mqtt

2 posts2 participants0 posts today

Hallo und guten Abend zusammen!

Für unser Projekt #mapleHome haben wir uns kürzlich einen neuen #homeserver gegönnt und bereiten und den Umzug unseres #Smarthome und einiger Apps/Tools vor. Bislang läuft unser #HomeAssistant OS auf einem Raspberry Pi 4 - soweit so gut.
Was mich persönlich immer nicht ganz so glücklich macht ist, dass die erforderlichen Add-ons und Zusatzdienste eben zu 100% vom gleichen System abhängen. So ist ja z.B. zigbee2mqtt ebenfalls "offline", wenn ein Update mit Neustart durchgeführt wird ...

Meine Idee:
Ich möchte zusätzliche Server/Dienste wie #zigbee2mqtt, den #MQTT Broker, Datenbanken, ... ein eigene VMs/Container auslagern. Dazu läuft #proxmox auf dem Server, für Home Assistant wird es eine VM geben und eben auch eine VM für #Docker.

Habt ihr es auch so oder so ähnlich umgesetzt? Bin ich gedanklich auf dem Holzweg? Oder würdet ihr noch weiter gehen?

Danke schonmal und allen einen schönen Sonntagabend!

Continued thread

And this is a possible update. The command synopsis is now split up into multiple logical sections to make it easier to find related options and ignore ones you aren't interested in. As a consequence, it occupies about a full screen height.

I think it's clearer, but I'm concerned the large amount of screen use is offputting.

Any thoughts?

Parsing the Elite Dangerous Journal

I gave in and changed my event forwarding method in node-red for the Elite Dangerous Journal. This file is updated on various in-game events but in a way that makes it difficult to get new events only since last update. Another problem is that it’s not really a valid JSON file because it has one JSON per line but it’s not a valid JSON array. This is why it has to be parsed line by line and mashed together by event type (name) again to get the latest data for each event type per dump. Each event has it’s own timestamp by set by the game. The latest timestamp is now saved on the special flow const so node-red keeps the value in the “global” memory of the current flow:

msg.payload.event = "Journal";let newJournalTimestamp = flow.lastJournalTimestamp;Object.keys(msg.payload).forEach((key) => {  if (msg.payload[key].timestamp) {    const keyTimestamp = new Date(msg.payload[key].timestamp).getTime();    if (!flow.lastJournalTimestamp || flow.lastJournalTimestamp < keyTimestamp) {      // this entry is new - keep it. MULTIPLE events may have the      //  same timestamp so wait with reassigning so we don't skip      //  em or get the latest a 2nd time if nothing else changes.      // update the next latest timestamp if this is newer      if(!newJournalTimestamp || newJournalTimestamp < keyTimestamp) {        newJournalTimestamp = keyTimestamp;      }    } else {      // lastJournalTimestamp is newer, skip this      msg.payload[key] = null;    }  }});// make sure this is a valid date for the next timeflow.lastJournalTimestamp = newJournalTimestamp || new Date().getTime();// remove all nulled events from the payloadmsg.payload = Object.fromEntries(  Object.entries(msg.payload).filter(([_, p]) => p !== null));msg.payload.timestamp = new Date(flow.lastJournalTimestamp);return { payload: msg.payload };

So I do now keep track of the last read timestamp and reject every event that is older than the last read keeping the Journal dump smaller. This way I don’t have to try to keep track of the “latest” event to drag data from. Refuelling e.g. can happen from whopping 4 (or more) different events and it’s painful to compare all and check which one is the latest to keep track of the real current fuel levels for each tank.

Downside is I won’t get a full set of data for the current session any more if I have to reload my HUD app. This could be mitigated by using MQTT though where I could simply persist each event topic. That is already implemented and I can choose between SocketIO or MQTT in my app anyway.

https://beko.famkos.net/2025/03/29/parsing-the-elite-dangerous-journal/

Meshtastic - MeshCore - Reticulum: Warum Sideband (Reticulum) zurzeit meine №1 ist

Jedes der drei oben genannten (Mesh) Systeme hat sicherlich seine Vor- und seine Nachteile. Reticulum kombiniert allerdings einige der (mir!) wichtigen Funktionen:

Es legt einen großen Wert auf Sicherheit (Verschlüsselung). Wer also Messenger wie #Session, #Threema oder #Signal statt #WhatsApp bevorzugt, lieg mit Reticulum (Sideband) sicherlich auch nicht falsch.

Reticulum ist dezentral (!) und selbstorganisierend. Andere Mesh-Netzwerke, die neben der Funkanbindung (LoRa), noch Zugänge untereinander über einen #MQTT-Server anbieten, funktionieren nur, solange diese Server online und nicht überlastet sind. Sideband lässt sich auch ganz einfach über das Internet nutzen und wenn dies ausfallen sollte, gibt es ja auch noch

LoRa (Funk) Verbindungen für Not- und Krisensituationen. Es lassen sich so einfach und mit kostengünstiger Hardware lokale Netzwerke aufbauen.

Ob ich also an einem PC mit Interzugang sitze, oder mein Smartphone mit Mobilfunkanbindung (oder eben auch mit einem über Bluetooth verbundenen LoRa Device) nutze, ich bin dann Teil des Netzwerkes und kann auf all diesen Geräten erreicht werden und Nachrichten versenden.

Ich weiß jetzt nicht mehr genau, wer diese Frage eigentlich gestellt hatte, aber ich hoffe, diese Erklärung hilft weiter. 😀

I've been developing a MQTT GUI client called MQTTy (the name is not very original but I needed the word MQTT in it). That will help me and hopefully help others, to develop, test and debug their IoT applications that utilizes the MQTT protocol.

It's written in Rust, completely free software, licensed under the terms of GPL 3.0 or later versions.

Currently the app does not hit the MVP stage, so there is a lot of work to do to reach it.

#foss#mqtt#rust

Bitten again by a certain MQTT broker defaulting to a max message size of 1MB out of the box.

And the logs really don't make it clear why it's just disconnected the client (and since it was a QOS2 message, the client then appears to fail to reconnect as it tries to re-send the message)

🌐 ESP32 IoT Dashboard using MQTT - Real-time Monitoring 🌡️💧

If anyone is interested in getting this IoT app, just leave a comment below, and I will gladly send you the app! ✅

Using ESP32 to send real-time sensor data (temperature, water level, etc.) to a customized MQTT dashboard app. 📊 You can monitor and visualize your data live from your phone!

ESP32 eBooks 📚
bokfive.com/esp32

#ESP32#IoT#MQTT

Hmm, curl's MQTT support doesn't appear to be useful if subscribing to multiple topics or messages.

It outputs a raw byte stream that starts with the 2 byte topic length, then the topic and finally the payload. It concatenates multiple messages like this, so there is no way to determine the payload length and parse out individual messages.

It also buffers output, so if you have a small message it won't write it to the file when you kill the process without adding '-N'

Okay, now how do I let Home Assistant know that it can send commands to #MQTT, that the #heatpump will then accept?
I think it is something with the `command` topic and using the environmental type for the discovery... But it's lacking clear documentation

Jemensch Hier Erfahrungen mit Strom Zählern auf Hutschiene für einzelne Stromkreise?

Was ich mir vorstelle, aber nicht finde: ein Gerät was Daten von mehreren einzelnen Stromkreisen zusammen führt. Mit #mqtt #rest oder anderer offener Schnittstelle.