Plugin: 1-Wire-NG
Einklappen
X
-
Es gibt ein neues PRE-Release (Version 1.0.0), welches die letzten gemeldeten Bugs fixt. Wenn innerhalb der nächsten Woche hier keine größeren Probleme gemeldet werden, wird 1.0.0 das erste Stable Release.
🇺🇦 Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine
LoxBerry - Beyond the Limits
-
Version 1.0.1 wurde als Stable veröffentlicht:
Download: https://github.com/mschlenstedt/LoxB...e-NG-1.0.1.zip
Wiki: https://www.loxwiki.eu/x/3gmcAw🇺🇦 Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine
LoxBerry - Beyond the Limits
Kommentar
-
Also ersteinmal vielen Dank für deine Arbeit, aber für meinen Zweck, mit RFID-Reader haut das vorne und hinten noch nicht so recht hin.
Ausgangssituation: Gestern alles frisch aufgesetzt; ein RFID-Reader; 8 RFID-Chips; alle wurden erkannt und im Plugin mit einem Namen und den empfohlenen Einstellungen für iButtons versehen.
Folgende Probleme habe ich aktuell:
1. Nur bei 3 der 8 Chips sieht man im MQTT Gateway eine Übertragung an den Miniserver
2. einer dieser drei Chips wurde nicht mit seinem konfigurierten Namen, sondern mit seiner Adresse übertragen (z.B. "owfs_status_01.671702200100_present"), zudem wird bei diesem die Adresse in einem anderen Format übertragen (01.671702200100), während bei den anderen beiden die Adresse ohne den Punkt übertragen wird; nach dieser einmaligen Übertragung löst auch dieser Chip keine weiteren Übertragungen aus, obwohl er vom OWFS erkannt wird
3. bei 2 der 3 Chips wird bei owfs_status_NAME_Uncached eine 0 übertragen, obwohl bei allen Chips im Plugin Uncached Reading aktiviert ist
4. für iButtons wird empfohlen, bei Aktualisierung 0.1 einzutragen - es lässt sich hier jedoch kein kleinerer Wert als 1 hinterlegen
5. Manche Chips werden sehr schnell registriert, bei anderen dauert es bis zu 10 Sekunden; besonders nach einem Neustart dauert es manchmal fast eine halbe Minute bis der OWFS mal einen angehaltenen Chip anzeigt, geschweige denn ihn nach wegnehmen wieder raus nimmt
6. nach einem Neustart lösen die beiden ursprünglich funktionierenden Chips keine Übertragungen mehr aus, dafür geht ein anderer; nach einem weiteren Neustart geht gar nichts mehr
7. Was die Erkennungszeit deutlich verkürzt ist das herabsetzen des Directory timeouts für den jeweiligen Bus im OWFS von 60 auf 1 Sekunde - diese Einstellung wird jedoch bei jedem Neustart zurückgesetzt
Für Temperatursensoren mag das alles ja funktionieren, aber für RFID ist es eine Katastrophe. Ich bin für jeden Hinweis und jede Anpassung dankbar, die mich vielleicht doch noch zu einer funktionierenden Lösung bringt, werde mich aber erst einmal dem alten Plugin widmen, in der Hoffnung, dass dieses für meine Zwecke besser funktioniert.
Das die RFID-Erkennung langsam ist, ist ja das eine, was mich aber vor allem wundert ist, dass die Kommunikation über MQTT so unzuverlässig ist. In den Logs konnte ich leider auch nichts finden.
Miniserver, 2x 1-Wire-Extension (iButtons, RFID, Temperatur- und Helligkeitssensoren, Fensterkontakte), DMX-Extension, KNX (Aktoren, Eingänge, BWM), Wassermelder inkl. Grünbeck GENO-STOP, Homematic, Hue, Netatmo, 4x Loxberry (Hardware + VM), FHEM, Zehnder Q350, Grünbeck SoftliQ SC:18, CalDAV-Anbindung, WLAN-Anwesenheit (Ubiquiti), Füllstandsmessung Zisterne, halbautomatische Rasenbewässerung, Sprachsteuerung via Alexa (HA-Bridge)Kommentar
-
Zunächst müsste man herausfinden, wo das Problem wirklich liegt. Du schreibst ja selbst, dass OWFS Probleme hat die Chips zu erkennen. Damit kann das Plugin dann auch nichts mehr machen.🇺🇦 Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine
LoxBerry - Beyond the Limits
Kommentar
-
Nene, der OWFS erkennt alle Chips zuverlässig ... dauert nur bei manchen länger als bei anderen - hängt vllt. damit zusammen, dass das mit dem uncached möglicherweise nicht richtig funktioniert.
Auch das Plugin zeigt ja alle Chips problemlos an ... nur wird halt meist nichts per MQTT übertragen. Im MQTT Plugin kommt einfach nichts an.
-
-
Ok, dann müsstest Du das Plugin auf Debug stellen und die Abfrage auf 0.1 Sekunden (das geht erst ab LoxBerry 2.0.1!). Dann siehst Du im Logfile alle 0,1 Sekunden einen Eintrag und er sagt Dir auch, ob er das weitergeleitet hat an den Broker.
Wie lang ist denn der Impuls des RFID-Lesers, wenn Du die Karte davor hälst? Oder ist die wie ein iButton solange am Bus, bis Du sie wieder wegnimmst?
Ist schon recht komisch, was Du da schilderst. Leider habe ich hier kein Testequipment dazu, sonst könnte ich es direkt testen. Wenn mir jemand einen Leser mit Karte zur Verfügung stellen kann, dann könnte ich es direkt debuggen.🇺🇦 Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine
LoxBerry - Beyond the Limits
Kommentar
-
Neueste Plugin-Version drauf? Wo genau ist der kleinste Wert "1"? Screenshot? -
Hallo zusammen, da das aktuelle 1-Wire-Plugin leider nicht mehr mit LoxBerry 2.0 läuft (auf Grund eines fehlerhaften OWFS-Pakets in Debian Buster), habe ich ein neues 1-Wire-Plugin von Grund auf neu programmiert (1-Wire-NG = Next Generation). Die Idee des Plugins basiert auf dem Plugin von hismastersvoice (Dieter), der zum
Habe ich hier eingefügt.
-
Der RFID-Reader ist wie eine iButton-Kontaktfläche unsichtbar und die Chips verhalten sich wie iButtons und werden als DS2401 erkannt. Solange ein Chip im Lesebereich des Readers ist, sieht er aus wie ein iButton am Bus.
Ich habe die 2.0.1.3 installiert, kann aber keine Werte kleiner 1 eintragen, egal ob mit Punkt oder Komma.
Ich meine im Log des 1-Wire plugins stand auch auf debug nicht viel brauchbares drin, aber ich schaue mir das morgen noch einmal in Ruhe an.
Natürlich könnte ich auch nochmal testen, ob es mit richtigen iButtons die gleichen Probleme gibt.
Ich melde mich morgen nochmal.Zuletzt geändert von ToNKeY; 30.01.2020, 17:59.Miniserver, 2x 1-Wire-Extension (iButtons, RFID, Temperatur- und Helligkeitssensoren, Fensterkontakte), DMX-Extension, KNX (Aktoren, Eingänge, BWM), Wassermelder inkl. Grünbeck GENO-STOP, Homematic, Hue, Netatmo, 4x Loxberry (Hardware + VM), FHEM, Zehnder Q350, Grünbeck SoftliQ SC:18, CalDAV-Anbindung, WLAN-Anwesenheit (Ubiquiti), Füllstandsmessung Zisterne, halbautomatische Rasenbewässerung, Sprachsteuerung via Alexa (HA-Bridge)Kommentar
-
Ok. Das mit den Werten kleiner 1 schaue ich mir an. Das muss eigentlich gehen.
bzgl. Log: du musst nach Umstellung auf Debug den owfs neu starten. Also einfach nochmal Einstellungen speichern. Dann wird er gesprächig.🇺🇦 Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine
LoxBerry - Beyond the Limits
Kommentar
-
Also sobald ich bei einem Gerät einen Punkt oder ein Komma im Feld für die Refreshzeit mache wird es rot. Wenn ich 0.1 versuche zu speichern sagt es mir "Der Wert muss mindestens 0.1 sein.". 0.11 lässt sich aber speichern.
Der OWFS erkennt jederzeit zuverlässig und blitzschnell die Chips - im MQTT-Plugin kommen aber wieder nur bei 1 bis 2 von 8 Chips Daten rein, was sich auch mit dem Log des 1-Wire-Plugins deckt.
Testverlauf:
Ausgangssituation: nur gelb und weiß funktionieren
Neustart per Software
-> im MQTT-Plugin kommt gar nichts mehr an - OWFS aber i.O.
Neustart per Stromunterbrechung
-> nur blau funktioniert
Neustart per Stromunterbrechung
-> nur schwarz funktioniert
Neustart per Software
-> im MQTT-Plugin kommt gar nichts mehr an - OWFS aber i.O.
Neustart per Stromunterbrechung
-> nur rot funktioniert
Neustart per Stromunterbrechung
-> im MQTT-Plugin kommt gar nichts mehr an - OWFS aber i.O.
Neustart per Stromunterbrechung
-> nur grau funktioniert
Unabhängig davon: Ganz so wie iButtons scheinen die Chips nicht zu sein - alle ca. 3 oder 4 Sekunden fliegen die mal für den Bruchteil einer Sekunde weg.Miniserver, 2x 1-Wire-Extension (iButtons, RFID, Temperatur- und Helligkeitssensoren, Fensterkontakte), DMX-Extension, KNX (Aktoren, Eingänge, BWM), Wassermelder inkl. Grünbeck GENO-STOP, Homematic, Hue, Netatmo, 4x Loxberry (Hardware + VM), FHEM, Zehnder Q350, Grünbeck SoftliQ SC:18, CalDAV-Anbindung, WLAN-Anwesenheit (Ubiquiti), Füllstandsmessung Zisterne, halbautomatische Rasenbewässerung, Sprachsteuerung via Alexa (HA-Bridge)Kommentar
-
Tja, so kann ich das nicht debuggen. Was ist denn blau, schwarz, weiß?!!!! Was deckt sich mit dem Log? Schreibt er das Erkennen ins Log? Schreibt er, ob er's gesendet hat? Warum hängst Du nicht einfach mal das Log hier an? Am Besten Neustart, dann EIN Chip vor den Sensor hänhen und schauen was im Log passiert. Dann das Log hier anhängen.🇺🇦 Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine
LoxBerry - Beyond the Limits
Kommentar
-
Die unterschiedlichen Farben sind unterschiedliche Chips.
Im OWFS werden sie zuverlässig angezeigt sobald und so lange sie vor den reader gehalten werden.
Bei ein oder zwei Chips funktioniert alles perfekt. Bei den anderen passiert in beiden Plugins rein gar nichts, so als ob gar kein Chip vorgehalten werden würde, obwohl sie im OWFS ja auftauchen.
Ich habe nach jedem Neustart nacheinander alle Chips angehalten und die genannten Farben sind die, auf die die Plugins reagiert haben, auf alle anderen nicht.
Log kann ich am Montag anhängen, aber da gobts nicht viel zu sehen - entweder es funktioniert alles oder halt bei den meisten Chips gar nichts, wobei die funktionierenden Chips halt mit jedem Neustart wechseln.Miniserver, 2x 1-Wire-Extension (iButtons, RFID, Temperatur- und Helligkeitssensoren, Fensterkontakte), DMX-Extension, KNX (Aktoren, Eingänge, BWM), Wassermelder inkl. Grünbeck GENO-STOP, Homematic, Hue, Netatmo, 4x Loxberry (Hardware + VM), FHEM, Zehnder Q350, Grünbeck SoftliQ SC:18, CalDAV-Anbindung, WLAN-Anwesenheit (Ubiquiti), Füllstandsmessung Zisterne, halbautomatische Rasenbewässerung, Sprachsteuerung via Alexa (HA-Bridge)Kommentar
-
Hast Du denn alle Chips vorher unter "Devices" auch angelegt? Die müssen alle vorhanden sein, sonst erkennt das Plugin die Chips nicht, obwohl owfs sie eventuell schon hat. Du musst also jeden Chip quasi erst anlernen.🇺🇦 Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine
LoxBerry - Beyond the Limits
Kommentar
-
Hi,
Bei mir funktionieren die DS18B20 einwandfrei aber mit den iButtons habe ich Massive Probleme.
Erkannt wird der iButton ohne Probleme und lässt sich auch konfigurieren.
Wenn ich ihn dann Anlege stürzt meistens der OWHTTPD ab. (startet dann aber auch selber wieder neu)
OWServer läuft (PID 9181) | OWHTTPD läuft nicht | OWFS2MQTT läuft (PID 9199)
Ab und zu läuft es dann aber da muß der iButton aber locker 30 Sekunden am Reader hängen.
Im log steht nix oder ich bin zu blöd es richtig einzustellen.
Gruß
Siggi
Edit:
Der Bus hängt an einem USB Busmaster
Die Namen die ich im Plugin für den iButton vergebe werden im MQTT nicht AngezeigtZuletzt geändert von Siggi; 05.02.2020, 04:34.Kommentar
-
Sind das normale 1990 iButton oder die DS2401? Wenn der OWFS abstürzt ist das kein gutes Zeichen. Verkabelung wirklich in Ordnung? Nur mal einen einzelnen iButton getestet?
Das die Namen nicht mit übermittelt werden muss ich mir anschauen. Das wäre dann ein Bug.🇺🇦 Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine
LoxBerry - Beyond the Limits
Kommentar
-
Das sind normale 1990 iButton´s
Verkabelung passt zu 100%
Das ganze System mit den Sensoren und den iButton´s ist seit über einem Jahr mit Loxberry 1.0 Problemlos gelaufen.
Im Haus gibt es noch einen Loxberry 1.0 mit dem "alten" 1-Wire Plugin und auch hier funktioniert alles wie gewohnt normal.
Kommentar
-
Die Namen werden definitiv nicht mit ins MQTT übernommen.
Brauchst du irgendwelche log´s oder wie könnte ich weiterhelfen ?
Is es eigentlich Normal das der Prozess - owfs2mqtt.pl - immer so um die 40% CPU Auslastung hat ? (Rpi 3b+)Kommentar
-
Kurzer Blick in Michaels Code, nichts Auffälliges entdeckt.
Loglevel auf Debug stellen, alles einstellen wie gewünscht, neu starten, bei Fehler das Log herunterladen und hier als ZIP anhängen. -
Wie Christian sagt. Ich habe aber selbst noch nicht reingeschaut. Bin im Urlaub. Wenn du das Abrufintervall sehr kurz wählst und viele Sensoren hast, wird der Pi stark belastet.
-
Kommentar