Servus, es gibt einige Themen bezüglich LoRa aber ich habe mein Problem trotzdem nicht lösen können. :-[
Ich habe eine Dragino LPS8 LoRa Gateway an dem ich ein LHT65N Temperatursensor angebunden habe.
In der TTN Netzwerk funktioniert auch alles und ich kriege alle 20 Minuten Temperatur- und Luftfeuchtigkeitswerte in der TTN Console angezeigt.
(Dennoch: warum muss LoRa so mega kompliziert sein? Ging das nicht einfacher... ::) )
Auf dem LPS8 habe ich MQTT aktiviert mit der Server Adresse und port von meinen FHEM MQTT Server.
(Das FHEM MQTT Server verwende ich schon seit lange mit ein paar Schaltbaren Steckdosen.)
Autocreate an der MQTT Server ist an allerdings hatte es die LPS8 client in eine hidden room platziert. Warum?
(Hab es erst gesehen als ich das Device gelistet habe für diese Nachricht.)
Was ich nicht verstehe: wie muss ich das LHT65N "durchreichen"?
Muss ich es irgendwie im LPS8 definieren oder wie kommen die Temperaturdaten in FHEM an?
Bis jetzt taucht es in FHEM nicht auf und mir fehlt eine höhere Schulabschluss um LoRa überhaupt verstehen zu können...
ZitatAutocreate an der MQTT Server ist an allerdings hatte es die LPS8 client in eine hidden room platziert.
Kannst Du bitte uns ein Listing zeigen?
Im hidden room ist ueblicherweise die Verbindungsinstanz vom MQTT2_SERVER, weil man das normalerweise nicht sehen will, genauso wie die Verbundingen zum Browser, usw.
Autocreate legt dann eine MQTT2_DEVICE Instanz an, wenn der MQTT Client was sendet, _und_ die Clientid des Senders nicht nach mosquitto_pub riecht : /^(mosqpub|mosq_)/
Letzteres deswegen, weil mosquitto_pub in der Voreinstellung Zufallsids generiert, und ohne die obige Einschraenkung beim Testen mit mosquitto_pub sinnlose MQTT2_DEVICE Instanzen angelegt werden.
Danke für Dein Antwort... Moskitos mag ich nicht... ;D mehr habe ich nicht verstanden. :-*
Das ist mein MQTT Server:
Internals:
CONNECTS 7
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 1883 global
FD 74
FUUID 61f43bb1-f33f-0963-4ae1-aed17d928bf2c01d
NAME mqttBroker
NR 575
PORT 1883
STATE Initialized
TYPE MQTT2_SERVER
eventCount 10
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2025-11-23 12:57:50 nrclients 4
2025-11-08 17:20:10 state Initialized
clients:
mqttBroker_192.168.10.122_50642 1
mqttBroker_192.168.10.46_52924 1
mqttBroker_192.168.10.77_58166 1
mqttBroker_192.168.10.78_59061 1
hmccu:
retain:
Attributes:
autocreate simple
room MQTT2
192.168.10.46 ist das LPS8
Das ist der hidden Device:
Internals:
BUF
FD 69
NAME mqttBroker_192.168.10.46_52924
NR 10006941
PEER 192.168.10.46
PORT 52924
SNAME mqttBroker
SSL
STATE Connected
TEMPORARY 1
TYPE MQTT2_SERVER
WBCallback
cflags 2
cid dragino-21cd0c
keepalive 60
lastMsgTime 1763931050.55298
protoNum 4
protoTxt MQTT
READINGS:
2025-11-23 12:57:50 state Connected
hmccu:
subscriptions:
v1//things/dragino-21cd0c/# 1763899070.87848
Attributes:
alias DraginoLPS8
autocreate simple
room MQTT2_DEVICE
ZitatDas ist der hidden Device:
Das ist (wie oben geschrieben) eine Verbindungs-Instanz vom MQTT2_SERVER, d.h. representiert die eigentliche Verbindung zwischen Client und FHEM.
Da man damit als Benutzer normalerweise nichts sinnvolles anstellen kann, und die meisten verwirrt, landet es im hidden Raum.
Mit "delete <name>" kann man diese Verbindung zumachen.
Ob das sinnvoll ist, darf jeder fuer sich ueberlegen.
Hi Thinman,
das hatten wir hier https://forum.fhem.de/index.php?topic=140070.msg1327692#msg1327692
schon mal diskutiert, im link fuer Chirpstack aber fuer TTN gehts das aequivalent.
Es gibt die beiden Moeglichkeiten, ueber die 1) MQTT server definition im Gateway selbst, oder ueber die 2) MQTT integration in TTN. Du hast im Moment sowie ich das verstehe 1). Das ist aber alles im oben verlinkten Beitrag beschrieben.
Danke, die verlinkte Thema habe ich schon mehrmals durchgelesen aber es hilft mir nicht weiter:
- ich habe ein LPS8 und keine LPS8V2. Das ältere Modell hat noch keine integrierte MQTT Server. Nur ein Client, wo ich die FHEM MQTT Server eintragen kann.
- ich verwende das TTN Server und habe keine eigene (Chirpstack) Server installiert.
Wenn ich richtig verstanden habe, brauche ich TTN nur um mein Thermometer device an meine Gateway anbinden zu können. Das habe ich gemacht und in der TTN Oberfläche sehe ich auch alle 20 Minuten die Daten. (Das payload decoder habe ich auch im TTN definiert)
Das MQTT Client im Gateway brauche ich um die Daten an mein FHEM MQTT Server weiter zu reichen. Das Hidden device welches das autocreate angelegt hat ist (wenn ich Rudi richtig verstanden habe) ist dieser Verbindung zwischen der LPS8 MQTT Client und mein FHEM MQTT Server.
(Ist aber für die Auswertung der Temperatur Daten nutzlos, daher hidden.)
Ich verstehe aber immer noch nicht:
-warum kein FHEM MQTT device für mein Temperatursensor angelegt wird?
Muss irgend ein "forwarding" auf der LPS8 eingerichtet werden?
-ob ich die payload Entschlüsselung FHEM seitig machen muss weil der TTN Server eigentlich gar nicht benutzt wird (nur fürs pairen).
OK, ich habe beides TTN und Chirpstack eingerichtet. Ich kann Dir nur zeigen wie meine funktionierende Lösung für TTN aussieht:
- Im TTN Webfrontend: Bild 1
https://eu1.cloud.thethings.network/console/applications unter Applications -> "Add application" habe ich eine MQTT integration eingerichtet, hier mit dem Label "FHEM TTN MQTT" Interface. Dort unter "connection credentials" einen eigenen Usernamen u Passwort vergeben. Der TTN server ist immer eu1.cloud.thethings.network:1883 glaube ich.
-In FHEM:
A) Client für den TTN server einrichten
defmod myTTN MQTT2_CLIENT eu1.cloud.thethings.network:1883
attr my TTN username <DeinUsername>
Das Password wird über den set Befehl vergeben.
b) Temperatur Device einrichten (Bei mir ist das ein Dragino LHT65)
defmod TTN_DR_LHT65 MQTT2_DEVICE myTTN
attr TTN_DR_LHT65 IODev myTTN
attr TTN_DR_LHT65 readingList myTTN:v3/<username>/devices/eui-otaa-abcdefg123456789/up:.* { json2nameValue($EVENT) }
Die readingList musst Du dann selber zusammenbauen, ich habe damals glaube ich im MQTT explorer geschaut, oder Du abonnierst erstmal alle Topics.
Bild 2 ist der screenshot vom LoRa Gateway, wo Du den MQTT Client eingerichtet hast, das benutze ich aber gar nicht.
Hoffe das hilft. Beste Grüsse!
Vielen Dank. So langsam kapiere ich es...
Wenn ich richtig verstehe, kann ich den LPS8 (ohne V2) nicht ohne das TTN Network verwenden weil um die Daten von der Sensor zu "broadcasten" ein MQTT Server und nicht nur ein MQTT Client braucht und der LPS8 hat ja nur ein Client.
Ist natürlich doof, dass die Messwerte erst um die halbe Welt tingeln müssen um danach wieder bei mir ausgewertet zu werden.
::) LoRa wird als was ganz tolles, neues angepriesen aber am Ende ist es wieder nur ein überkompliziertes (und sehr teures) System welches nur einigen Hersteller zu gute kommen. Hat man keine Ahnung, fällt man den schönen Werbewelt herein... Business as usual
Ich versuche es dann so wie Du beschrieben hast und dann schauen wir weiter.
Vielen Dank für die detaillierte Beschreibung!
Also das TTN (oder Chirpstack) Netzwerk brauchst Du, ohne das kannst Du deine Devices nicht verwenden. Weil die Devices müssen ja in einem LoRaWan Netzwerk angemeldet sein und dort von einem Gateway empfangen werden. Bei TTN kannst Du deinen Temperatursensor auch mit nach Italien oder Malta nehmen, solange der Sensor eine Verbindung zu einem TTN Gateway hat, bekommst Du zu Hause in FHEM die Daten. Das schöne an LoRaWan ist die Reichweite, bei mir über 5 Etagen mit Betondecken bis in den Keller. Oder ich kann mit dem Temperatursensor auch um den Häuserblock laufen (wer macht sowas?) und empfange die Daten trotz dichter Bebauung. Das geht mit WLAN/BT/Homematic/etc so einfach nicht.
Kommt eben auf den Einsatzzweck an.
Alternativ machst Du Chirpstack, dann bleiben deine Daten bei Dir und sind auch nur mit deinem eigenen (einzelnen) Gateway gekoppelt und werden auch nur in deinem privaten Chirpstack Netzwerk empfangen.
Meiner Meinung nach kannst Du das LPS8 auch mit Chirpstack verwenden. dann muss man nur im Gateway bei der Server Adresss "<dei.ne.IP.Adr>" eintragen (also die IP adresse von dem Rechner wo Du Chirpstack installiert hast), anstelle von "eu1.cloud.thethings.network". Port ist ebenfalls 1700. Die Anmeldung von Devices im CS Netzwerk ist äquivalent zu TTN, kein Unterschied, und die Funktionalität ist die gleiche, CS ist halt offene Software..
Das ist alles, alles andere äquivalent zu oben, auch mit MQTT funktioniert das gleich, nur die MQTT Einrichtung ist ein bischen anders.
Chirpstack Installation und Einrichtung ist gut dokumentiert, aber man muss sich ein bischen durchbeissen. Vielleicht gibts das auch schon im Docker. Man muss ja keine Ports durchreichen, sollte also mit Docker auch einfach sein.
Zitat von: thinman am 24 November 2025, 18:42:53LoRa wird als was ganz tolles, neues angepriesen
"LoRa" ist einfach nur eine Abkürzung für "Long Range", also "große Reichweite".
Es beschreibt tatsächlich weder ein Übertragungsprotokoll noch ein fertiges Produkt irgendeines Herstellers.
Zitat von: betateilchen am 24 November 2025, 20:02:17Zitat von: thinman am 24 November 2025, 18:42:53LoRa wird als was ganz tolles, neues angepriesen
"LoRa" ist einfach nur eine Abkürzung für "Long Range", also "große Reichweite".
Es beschreibt tatsächlich weder ein Übertragungsprotokoll noch ein fertiges Produkt irgendeines Herstellers.
Stimmt, zumindest für LoRa. Ich hätte lieber LoRaWan schreiben sollen. Das ist die korrekte Bezeichnung welches dann die von mir erwähnte, komplizierte System beinhaltet.
Ich muss auf jeden Fall noch weiter damit beschäftigen...