If you are a #developer and need to combine several #protocol #bindings for an #IoT system, the ACME-CSE provides a great environment for learning and experimentation https://acmecse.net/home/Supported/ #CoAP #http #MQTT #WebSocket
If you are a #developer and need to combine several #protocol #bindings for an #IoT system, the ACME-CSE provides a great environment for learning and experimentation https://acmecse.net/home/Supported/ #CoAP #http #MQTT #WebSocket
Yay, it arrived. ODB2<-->MQTT gateway for the camper conversion.
https://www.meatpi.com/products/wican-pro
#camperautomation #homeautomation #obd2 #mqtt
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!
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/
Powering the Superbowl, The Olympics and Paris fashion shows with Elixir.
I connected with Cyanview in my work and as I unpacked what they were up to I couldn't believe my ears.
The case study is finally up. Enjoy.
#superbowl #mqtt
https://elixir-lang.org/blog/2025/03/25/cyanview-elixir-case/
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.
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)
The WolfMQTT client library in C now has WebSocket support. They test against VerneMQ as well.
https://www.wolfssl.com/announcing-websocket-support-in-wolfmqtt/
#MQTT
Hey, look what I found after 2 weeks of searching!
An actual spec for the #HomeAssistant auto-discovery #MQTT!
The spec is about as weird as I expected.
stat_t,stat_t_tmpl,json_attr_t,stat_on (which is an abbreviation for state_on)...
Holy mother of the flying #spaghetti monster's meatballs they made it hard to find and use
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
https://bokfive.com/esp32
Raised an issue to discuss how to improve curl's MQTT message output.
https://github.com/curl/curl/issues/16633
Comments and insight requested to plan a possible PR as I can't see a way to fix it without it being a breaking change to current behaviour.
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'
Throwing this question out there:
Is it possible to remap MQTT-messages from a certain IP (or user) to another one?
I only find documentation about remapping outgoing topics (bridge)
I've made a #riscv snap build of #mosquitto #mqtt available on the edge channel. If you've got a riscv device and can give it a try, please let me know if it works ok for you