Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
mastodon.gamedev.place is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon server focused on game development and related topics.

Administered by:

Server stats:

5.3K
active users

mastodon.gamedev.place: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#mqtt

4 posts4 participants0 posts today
Public *
Ron

Die Installation einer Wallbox haben wir genutzt, einen Shelly Pro 3EM in den Sicherungskasten zu integrieren.

Ich wollte endlich sehen, wieviel Leistung wir wirklich abrufen.

Der Shelly ist ein 3-Phasen-Messgerät. Die Leistung wird induktiv gemessen.

Die Installation war einfach, da spare ich mir ein näheres Beschreiben.

Doch der erste Eindruck war ernüchternd. keines meiner erhofften Ziele wurde unmittelbar erreicht (Bild 1)

Weder konnte ich sagen, wieviel Leistung WIRKLICH gerade von meinen Geräten gezogen wurde, noch wieviel in Netz an eigener Leistung eingespeist wurde.

Zum Glück messe ich den Solar-Ertrag separat und speichere diesen Wert in ein laufend (alle 5 Sekunden) aktualisiertes Reading.

Addiere ich nun die Active Power aller drei Phasen und addiere den Solarertrag, habe ich den gesamten Leistungsabruf.

Der Shelly wird in FHEM per MQTT eingebunden.
Am state-format etwas herumgefriemelt, ergibt sich auch eine akzeptable Anzeige (Bild 2).

Wozu brauche ich diesen Gesamtleistungswert? Ich kann damit das Zuschalten der Batterie viel besser auf den Leistungspunkt steuern. Vor dem Shelly fehlten mir immer ca. 50-150 Watt (+ Heizungskessel, dessen Messschalter mir zwischenzeitlich kaputt gegangen ist. Die Heizung selbst zieht zwischen 1500 Watt (Anzünden) und 150 Watt normaler Betrieb mit allen Pumpen etc.), die ich nicht gemessen hatte und die damit immer aus dem Netz bezogen werden mussten, obwohl Akku-Strom vorhanden war. Ganz sauber ist das noch nicht, da die Victron-Orions keine auf den Punkt gebrachte Leistung bereitstellen. Ein Orion kann bis zu 50 Watt mehr (oder weniger) Leistung liefern, als er grundsätzlich soll. Und auch während des Betriebes bleibt die Leistung nicht konstant. Insbesondere wenn die Orions heiß werden, und sie werden SEHR heiß, sinkt ihr Wirkungsgrad.

Daher investiere ich ja soviele Ideen in die Kühlung. Mittlerweile wird kein Orion mehr über 60°C warm, selbst die 50°C werden nur noch selten überschritten. Positiv ist, dass die Kühlung an der Energie-Ausbeute nichts negativ verändert hat. Denn der bessere Wirkungsgrad wird durch die Kühlung nicht aufgefressen. Die Geräte fahren also auf weniger Verschleiß und liefern sogar geringfügig mehr Energie als Strom, als durch die Kühlung "verloren" geht.

BTW: Der Energieverbrauch, der mit dem Shelly gemessen werden kann, interessiert mich allerdings gar nicht. Ich habe direkt vor unserem Zähler einen Sensor sitzen, der ca. alle 5 min den Zählerstand übermittelt. Da sich der Zähler innerhalb von 5 min nur wenig ändert, reicht mir das.

Bild 1
#shelly#fhem#victron
Public
cypher2020

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
Public
Roger Light

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?

Man page output of mosquitto_sub, where 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.
#mosquitto#mqtt#documentation
Public
Beko Pharm

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/

#EliteDangerous#EliteDangerousOdyssey#homeCockpit
Public
Daniele Verducci 🧉
THIS.
https://youtu.be/5M_hmwBBPnc?si=c00pyXc8utkBc103

@geerlingguy absolutely nailed it. The problem is, the vast majority of the "smart" appliances does not have a mean to use it locally. It would be as simple as dumping all the sensors on #MQTT or some other standard protocol, no need to reinvent the weel. But if you look at the #homeassistant integrations, you realize the vast mayority relies on the manufacturer webservices, intercepting them in some way and usually requiring a token from their servers. This means that if the manufacturer drops support, you lose access to your own appliance, if there's no internet connection it doesn't work, an anyway there's always some delay and some hidden profilation...
YouTubeI won't connect my dishwasher to your stupid cloudBy Level 2 Jeff
Public
Memo

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. 😀

Bildbeschreibung: Screenshot aus dem Messenger Sideband.
#Datenschutz#Privacy#Messenger
Public
AliveDevil

I have some #MQTT entity in #HomeAssistant with customized entity names.
How can I, without directly selecting that entity, get the entity by-function from the device?
MQTT topic is "temperature_sensor_select".
Also: Generically, so this should also work with #ZHA, instead of #Z2M.
In an automation, with a device-filter, how can I select an owned entity by-function?
This is everything I got.

#Zigbee
Public *
Oscar Pernia

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
ExploreLive feeds
About