Hallo zusammen,
ich habe bei eBay ein 1-Wire Busmaster mit 2x S0-Interface entdeckt. Läuft dieses Teil (http://www.ebay.de/itm/181567973441) unter fhem?
Viele Grüße
Frank
Hallo Frank,
das ist ein interessantes Teil. Bis zum Beweis des Gegenteils würde ich aber zunächst vermuten, dass das verwendete Protokoll auf dem USB ein proprietäres ist, zumindest keines, für das aktuell direkt oder indirekt Unterstützung durch FHEM besteht.
Bitte frage doch beim Anbieter nach, ob das Teil einen der von der owserver-Softwaresuite (siehe deren Webseite) unterstützten Busmaster emuliert. Falls ja, dann interessiert auch noch, wie sich die S0-Schnittstellen dabei einfinden.
Viele Grüße
Boris
Das Teil habe ich seit zwei Tagen auch in meinem Besitz. Eine Zusammenarbeit mit owserver ist mir nicht gelungen, allerdings habe ich owserver auch zuvor noch nie verwendet. Beim Hersteller kann man ein kleines Tool für verschiedene Plattformen herunterladen, dieses legt dann pro erkannten Busteilnehmer zwei Dateien an. Eine enthält die Rohdaten die andere die nackten Werte. Bei den beiden S0 Zählern ist es pro Zähler eine Datei, in der config lässt sich auch gleich ein Teiler zum Umrechnen definieren Bsp. 1000 Impulse ~ 1kW/h
Mit etwas Perl lassen sich die Werte bestimmt iüber die 99_myutils in fhem einbinden. Ich werde aber auf jeden Fall (und wenn es nur für mich selbst ist) für den Treiber von sms-giuard.de noch ein fhem Modul schreiben.
Ich habe folgende Antwort von dem Hersteller erhalten:
Einbinden in FHEM oder IP-Symcon:
Die 1wire-USB läuft auf der verwendeten Hardware und schreibt die Daten vom 1wire-USB-Master als Textfile in das lokale Filesystem. FHEM beruht auf Perl und somit können Daten aus Textfiles als aktuelle Sensorwerte übernommen werden.
IP-Symcon basiert auf PHP, auch hier können Textfiles sehr einfach eingelesen werden. Weitere spezielle Treiber dazu sind nicht notwendig. Ein anderer 1wire-Busmaster unter owfs kann parallel im System betrieben werden.
Hilft uns das weiter?
Danke für die Info. Kommt für mich nicht in Frage, weil es proprietärer Windows-Kram ist. Schade.
Wenn Du das Teil einsetzen willst, ist der Ansatz von wzut zu präferieren. Ihr werdet aber damit weitgehend alleine sein.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 30 Oktober 2014, 20:31:06
weil es proprietärer Windows-Kram ist. Schade.
Einspruch Hr. Doktor , wäre es das hätte ich bestimmt die Finger davon gelassen :)
Das Teil hat ein recht simples dokumentiertes Protokoll , Auszug aus der Doku :
der 1wire-USB-Master kann recht einfach mit einem seriellen Terminal auf Funktion überprüft werden:
a) serielle Schnittstelle einstellen auf 115200 8-N-1 kein Handshake RTS/CTS, kein On/Off Protokoll
b) Startbefehl eingeben, damit wird auch die Wandlung im Sensor ausgelöst: $?<CR>
c) mit angeschlossenen 1wire-Sensoren werden die gefundenen IDs gelistet: $0;o;1080974B020800BA;
das ,,o" steht für ,,ok" und die Checksumme der ID wurde geprüft und ist ok
d) danach gibt der 1wire-USB-Master die beiden S0-Zählerstände zurück: $S0;0;0;
e) die Werte der 1-wire Sensoren können nach 1s abgefragt werden mit: $0<CR> ... $63<CR>
f) danach gibt der 1wire-USB-Master die Daten des Sensors zurück: $0;o;31;00;4B;46;FF;FF;07;10;8D;64;
das ,,o" steht für ,,ok" und die Checksumme (9.Byte) der 8 Datenbytes wurde geprüft und ist ok (,,n" wäre ,,nicht ok")
die Beschreibung der 8 Datenbytes in Hex ist dem Sensordatenblatt zu entnehmen
das 10.Byte ist eine Checksumme für die serielle Übertragung (Byte1-9 aufaddiert).habe das gerade mal mit drei angeschlossenen DS1820 in einer seriellen Konsole getestet, klappt wunderbar. Sollte jetzt also kein großer Akt mehr sein das am WE in ein eigenes FHEM Modul zu packen.
Der Sinn erschließt sich mir nicht ganz - für dasselbe Geld kann man einen "echten" Busmaster mit DS2482 kaufen und einen 1-Wire Counter anhängen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 31 Oktober 2014, 04:25:23
... und einen 1-Wire Counter anhängen.
Ist dies denn so einfach? Gibt es dafür bereits Lösungen? Ich suche nämlich eine einfache Lösung, um einen S0-Zähler mitzählen/auslesen zu können.
zumindest nicht schwerer als andere 1Wire Geräte, in den Bus zu hängen ;)
Es gibt entweder Fertiglösungen á la http://www.eservice-online.de/1-Wire-Bus/Digital-Ein-und-Ausgang-Analog-Eingang-Zaehler/1-Wire-Dual-S0-Zaehlermodul.html
Oder du schaust dich mal in diesem Thread um, wenn man nur halbwegs geschickt mit dem Lötkolben ist, kann man sich auch seinen eigenen Counter zusammenbraten, mit dem sich unter anderen auch ein Entfernungsmesser realisieren lässt http://forum.fhem.de/index.php/topic,10962.0.html
Ich habe derzeit vier dieser Counter im Einsatz für meine vorhandenen Strom und Gaszähler
Greetz
Eldrik
Zitat von: Prof. Dr. Peter Henning am 31 Oktober 2014, 04:25:23
Der Sinn erschließt sich mir nicht ganz - für dasselbe Geld kann man einen "echten" Busmaster mit DS2482 kaufen und einen 1-Wire Counter anhängen.
Guter Punkt. Dieses Setup hatte ich zwei Jahre im Betrieb, bevor es der Blitzschlag im August zersemmelt hat.
Welchen 1-wire-Counter würdest Du verwenden? Ich hatte den DS2423. Der ist aber m.W. abgekündigt und nur noch vereinzelt für Unsummen (> 10 € pro Stück) zu bekommen.
Viele Grüße
Boris
Die von Thomas Müller geschriebene Software
http://www.tm3d.de/index.php/1-wire-device-mit-avr
zur Emulation eines DS2423 auf einem ATTiny ist inzwischen mehrfach erweitert worden, u.a. inklusive internem RAM und Ausfallsicherheit gegen Stromausfall. Damit ist ein (fast) 1:1 gegen den DS2423 austauschbares Bauteil realisiert - nur im DIP 8, statt in einem SMD Package
Die fortgeschrittenste Version wird hier diskutiert:
http://forum.fhem.de/index.php/topic,22431.0.html
In dem von dougie begonnenen Thread werden Platinen mit peripherer Anpassung an S0 vertrieben, sowie fertig geflashte ATTiny.
LG
pah
Wie bereits geschrieben legt das Interface automatisiert txt files an, in die die Werte der angeschlossenen Devices geschrieben werden. Einbinden in OWServer ist mir nicht gelungen. Um es anderweitig zu nutzen, müsste man wohl die "Firmware" ändern. Für FHEM imho eher ungeeignet.
wie letzte Woche versprochen , hier meine beiden FHEM Module für diesen Busmaster die so bei mir seit Sonntag laufen
Aufruf z.B mit define <name> USBMASTER /dev/ttyUSB0
ACHTUNG : seit September 2015 liefert der Hersteller die Sticks mit einer geänderten Baudrate aus (38400 statt bisher 115200).
Bei den neuen Sticks daher unbedingt die Baudrate beim define mit angeben :
define <name> USBMASTER /dev/ttyUSB0@38400
wenn autocreate an ist werden nach kurzer Zeit die am OW Bus angeschlossenen Temperatur Sensoren durch USBSLAVE angelegt.
Ich hatte bis jetzt keine Gelegenheit andere Sensoren am Bus als DS1820 & DS18B20 anzuschliessen, daher unterstützt z.Z. USBSLAVE auch keine anderen Ch
Unterstützung für den DS2423 bzw. den Clone kann ich noch nachschieben falls allgemeines Interesse an den beiden Modulen besteht.
Edit : ist ab 4.02.2021 durch normales FHEM update zu beziehen , Name : 00_OW2S0SMSGUARD.pm
Zitat von: Wzut am 04 November 2014, 20:34:01
... falls allgemeines Interesse an den beiden Modulen besteht.
Ich bin daran sehr interessiert. Bitte poste deine Entwicklungen weiter hier.
Viele Grüße und Danke
Frank
Hallo,
Dein Modul habe ich auch schon ausprobiert, und für den 1-Wire Bus funktioniert es einwandfrei.
Ich habe mir für meinen EHz ein IR zu S0 Interface gelötet und werde es die Tage einmal ausprobieren. Komm ich über Dein FHEM-Modul auch an den S0 Daten heran?
Gruß Knuffioda
Zitat von: Knuffioda am 01 Januar 2015, 22:00:53
Komm ich über Dein FHEM-Modul auch an den S0 Daten heran?
die beiden internen S0 Zähler des Moduls ? ja die zeigt USBMASTER als Readings an.
::)
Oh Ja, für dumme oder Blinde stand es ja da! Wenn man nur weiss was es mit A: und B: auf sich hat...
Sorry, newbie Fehler.
Auch dieser Teil vom USBMASTER funktioniert gut, ich kann nun das Signal einer IR Fernbedienung zählen, wenn das nun mit meinem eHz auch klappt, dann entwickelt sich dieses SMS-Guard S0/1Wire Gerät mit dem USBMastermodul, zu genau dem, was ich brauchte. Als Bonus waren alle verwendeten Komponenten nicht sehr teuer.
Zitat von: Knuffioda am 02 Januar 2015, 23:45:17
Wenn man nur weiss was es mit A: und B: auf sich hat...
Ja ich hätte die auch Counter1 und 2 nennen können :) hatte damals aber wohl OWCOUNT im Hinterkopf und da wird A und B verwendet.
Ich möchte ernsthaft anregen, die Module nicht USBMASTER und USBSLAVE zu nennen. Diese beiden Begriffe sind so generisch, dass man aus dem Namen kaum erraten kann, was sich dahinter verbirgt.
LG
pah
Kein Problem, da ich die noch nicht eingecheckt habe ist noch alles machbar bzw. ich bin offen für kreative Vorschläge :)
Vllt. etwas in die Richtung des Herstelles (smsguard.org ) ?
Also bei mir nennt sich das Bauteil schlicht "1W2S0".
Wie wärs mit "OW2S0" oder "OW2SOSMSGUARD" könnte man einfacher den anderen 1-Wire Modulen zuordnen.
Hallo,
das Modul läuft jetzt wie gesagt nicht schlecht. :) Ich hätte hier noch 2 DS2406 rumliegen, wenn Wzut das Modul darum erweitern würde, könnte ich diese dann daran einmal ausprobieren.
Hatte die 2406 schon an meinem COC, doch das klappte dort mit der Anzahl meiner Devices und der Buslast nicht wirklich. :'(
sorry , aber ob mit dem Modul noch was passiert hängt weniger von mir als vom Hersteller ab.
Wie es z.Z. ausschau fragt der dort verbaute 1W Busmaster jeden der erkannten Teilnehmer wie einen DS1820 ab ( Read Scratchpad) ohne sich um die Family ID zu kümmern. Ich hatte einen DS2423 Clone am Bus und die beiden Zähler wurden nicht ausgelesen. Ich habe mir dann in sofern weitergeholfen das ich die beiden 32 Bit Zählerwerte einfach ins Scratchpad um kopiert habe und nachher mit dem FHEM Modul wieder in zwei Werte zerlegt habe. Eine E-Mail Anfrage an den Support des Herstellers nach unterstützenden 1W Teilnehmern blieb leider unbeantwortet. D.h. so lange smsguard nicht an seiner Firmware nachbessert ist das Ding wirklich nur mit den beiden internen Zählern plus ein paar Temperatursensoren am Bus sinnvoll einsetzbar.
Hallo!
Ich benutze Dein Modul seit heute für meinen Gas- bzw. Wasserzähler.
Hast Du die Möglichkeit, auch noch eine Funktion zum resetten der beiden S0-Zähler einzubauen? Das würde mir sehr entgegenkommen.
Grüße
Niel
EDIT: Habe es gerade selber eingefügt. War gar nicht kompliziert.
Hallo Niel !
hab auch das Busmaster 2xS0-Interface jetzt in meinem FHEM-Server installiert läuft soweit richtig gut,kannst du mir sagen wie ich die beiden S0 Eingänge resetten kann,also wieder auf Null setzen , was und wie muss ich da noch hinzufügen...?
mfg
Hallo Niel,
ich habe deine beiden Dateien erfolgreich eingefügt,resetten klappt perfekt. (Danke)
wäre es auch möglich das man eine min/max Temperatur eines Sensors über 24 Stunden anzeigen kann? z.b. Aussen Sensor.
Welche S0 - Impulsgeber verwendet Ihr zum Gaszähler auslesen und wie rechnet Ihr die Daten dann um ?
mfg co010
Das Gerät ist eine technologische Sackgasse. Empfehlung: ordentlichen 1-Wire Busmaster. Es gibt genügend Beispiele dafür, wie man dann alle gewünschten Messwerte und Berechnungen erhalten kann.
LG
pah
Das mag ja so sein , aber nicht alle können mit dem Lötkolben so gut umgehen .
Und wenn es funktioniert ist doch alles OK.
Mann muss nicht alles schlecht reden was mann selbst nicht benutzen will.
Ich habe hier noch seit Ewigkeiten die Software S0-Recorde im Einsatz und möchte jetzt alles auf FHEM umstellen.
Dabei sind noch zwei alte USB Wandler , die ich warscheinlich ersetzen muss, deswegen finde ich die Lösung für 31 inkl. Versand recht Interessant. Wobei eine Erweiterund für den Raspi 2 noch interesannter wäre.
Hallo Joshibaer ,
ich hab das Teil seit ca 3 Wochen bei mir mit FHEM laufen,mit bis jetzt 32 Sensoren (DS18b20) und einer Gesamtbuslänge (Cat5) von 200 Metern ohne einen Ausfall.
geht auch im entfernten Gewächshaus,und gratis sind auch noch 2 S0- Schnittstellen dabei...
Ein richtiger 1W-Profibusmaster Kostet so um die 350.-Euro , also was will man mehr !!!
lg co010
Das ist, mit Verlaub, Unsinn. 25 Euro sind der Preis für einen USB Busmaster, fertig aufgebaut, wohlgemerkt.
LG
pah
Hallo!
Ich hänge hier mal meine angepassten Dateien an, da doch nach der Möglichkeit gefragt wird, wie man die S0-Zähler resetten kann.
Grüße
Niel
Per PN bin ich nach Quellen für vollwertige USB 1Wire Adapter gefragt worden.
Schaut bei EBay, den billigsten habe ich für 8 € gefunden:
http://m.ebay.com/itm/231260963718?_mwBanner=1
Und für weniger als 25 € incl. Versand: http://m.ebay.de/itm/1Wire-interface-USB-zu-1-Wire-Dallas-DS2480-1Wire-einfach-seriell-abfragen-/131571350410?nav=SEARCH
Etwas darüber
http://m.ebay.de/itm/171041719472?_mwBanner=1
http://www.fuchs-shop.com/de/shop/17/1/13372111/
Also noch mal der Tipp: SMSGuard Sonderlösung vergessen, Standardprodukte verwenden.
LG
pah
Nach stundenlanger Fehlersuche musste ich feststellen das bei mir der USB Stick auf ttyUSB1 liegt.
Ich habe ein neuen Raspi mir 1GB Hauptspeicher.
Jetzt die Frage wie habt ihr es Programmtechnisch realiesiert , den KW Verbrauch zu berechnen.
Guckst du hier. (http://www.fhemwiki.de/wiki/Stromz%C3%A4hler_und_1-Wire,_OWServer,_OWDevice) ;)
Ok danke , jetzt bin ich weiter gekommen wie im Log 1 zu sehen werden die Internen Zählimpule angezeigt
define FileLog_s0zaehler FileLog ./log/s0zaehler-%Y.log s0zaehler:.*
2015-08-29_18:30:36 s0zaehler A: 0
2015-08-29_18:30:36 s0zaehler B: 17586
2015-08-29_18:30:36 s0zaehler A:0 - B: 17586
2015-08-29_18:30:46 s0zaehler A: 0
2015-08-29_18:30:46 s0zaehler B: 17587
2015-08-29_18:30:46 s0zaehler A:0 - B: 17587
Nachdem ich es etwas modifiziert habe bekomme ich im Log 2 es so angezeigt.
Die Dopplung muss ich aber irgendwann noch enfernen.
define s0zaehlerab dummy
define notify_s0zaehler notify s0zaehler { \
my $a = ReadingsVal("s0zaehler","A",0)/1 ;; \
my $b = ReadingsVal("s0zaehler","B",0)/1 ;; \
my $text = "Z1: $a , Z2: $b " ;; \
fhem ("set s0zaehlerab $text") ;; \
}
define FileLog_s0zaehler_ab FileLog ./log/FileLog_s0zaehler_ab-%Y-%m.log s0zaehlerab
2015-08-29_18:58:44 s0zaehlerab Z1: 0 , Z2: 17688
2015-08-29_18:58:44 s0zaehlerab Z1: 0 , Z2: 17688
2015-08-29_18:58:54 s0zaehlerab Z1: 0 , Z2: 17689
2015-08-29_18:58:54 s0zaehlerab Z1: 0 , Z2: 17689
2015-08-29_18:59:04 s0zaehlerab Z1: 0 , Z2: 17690
2015-08-29_18:59:04 s0zaehlerab Z1: 0 , Z2: 17690
2015-08-29_18:59:14 s0zaehlerab Z1: 0 , Z2: 17690
2015-08-29_18:59:14 s0zaehlerab Z1: 0 , Z2: 17690
2015-08-29_18:59:24 s0zaehlerab Z1: 0 , Z2: 17691
2015-08-29_18:59:24 s0zaehlerab Z1: 0 , Z2: 17691
und zum Schluss noch der Aktuellen Zählerstand
attr s0zaehler stateFormat { sprintf("%.3f kWh %.3f kWh", ReadingsVal("s0zaehler","displayA","kWh"), ReadingsVal("s0zaehler","displayB","kWh"));; }
attr s0zaehler userReadings displayA {ReadingsVal("s0zaehler","A",0)/1000.0+AttrVal("s0zaehler","offsetA",0);;}, consumption_power differential {ReadingsVal("s0zaehler","A",0)*3600*0.001;;}, daily_power {ReadingsVal("s0zaehler","displayA",0)-Value("Dum_DP_Diff_D");;}, displayB {ReadingsVal("s0zaehler","B",0)/800.0+AttrVal("s0zaehler","offsetB",0);;}, consumption_power2 differential {ReadingsVal("s0zaehler","B",0)*3600*0.00125;;}, daily_power2 {ReadingsVal("s0zaehler","displayB",0)-Value("Dum_DG_Diff_D");;}
OW2S0SMSGUARD
s0zaehler 0.000 kWh 22.802 kWh
Alles Top .
In der Anleitung ist erklärt , wie ich den Tages und Monatswert berechne.
Ich möchte aber den Momentanverbrauch angezeigt bekommen.
Wie kann ich dieses Problem Lösen ?
Hier der ganze Code
define s0zaehler OW2S0SMSGUARD /dev/ttyUSB1
#z1 =1000/KWh
#z2 =800 /KWh
attr s0zaehler offsetA 00000.00
attr s0zaehler offsetB 00000.00
attr s0zaehler room Energie
attr s0zaehler stateFormat { sprintf("%.3f kWh %.3f kWh", ReadingsVal("s0zaehler","displayA","kWh"), ReadingsVal("s0zaehler","displayB","kWh"));; }
attr s0zaehler userReadings displayA {ReadingsVal("s0zaehler","A",0)/1000.0+AttrVal("s0zaehler","offsetA",0);;}, consumption_power differential {ReadingsVal("s0zaehler","A",0)*3600*0.001;;}, daily_power {ReadingsVal("s0zaehler","displayA",0)-Value("Dum_DP_Diff_D");;}, displayB {ReadingsVal("s0zaehler","B",0)/800.0+AttrVal("s0zaehler","offsetB",0);;}, consumption_power2 differential {ReadingsVal("s0zaehler","B",0)*3600*0.00125;;}, daily_power2 {ReadingsVal("s0zaehler","displayB",0)-Value("Dum_DG_Diff_D");;}
define FileLog_s0zaehler FileLog ./log/s0zaehler-%Y.log s0zaehler:.*
attr FileLog_s0zaehler logtype text
define s0zaehlerab dummy
define notify_s0zaehler notify s0zaehler { \
my $a = ReadingsVal("s0zaehler","A",0)/1 ;; \
my $b = ReadingsVal("s0zaehler","B",0)/1 ;; \
my $text = "Z1: $a , Z2: $b " ;; \
fhem ("set s0zaehlerab $text") ;; \
}
define FileLog_s0zaehler_ab FileLog ./log/FileLog_s0zaehler_ab-%Y-%m.log s0zaehlerab
Guck mal weiter unten bei "Plotfile Strom (stromverbrauch.gplot):" Darin siehst du, was du für den Momentanverbrauch loggen und plotten musst.
Ui da war ich wohl blind gewesen.
Mit
define s0zaehlerb_momentanverbrauch readingsProxy s0zaehler:consumption_power2
Habe ich den Wert der benötigt wird.
das ganze gerundet auf 3 Stellen nach dem Komma sieht so aus
define s0zaehlerb_momentanverbrauch readingsProxy s0zaehler
attr s0zaehlerb_momentanverbrauch room Energie
attr s0zaehlerb_momentanverbrauch stateFormat {sprintf("%.3f KW ",ReadingsVal("s0zaehler","consumption_power2",0)) }
Damit der Wert nicht zusehr schwankt frage ich ihn nur alle 30 sec ab.
define s0zaehler OW2S0SMSGUARD /dev/ttyUSB1 30
Auch das Doppellogproblem ist gelösst indem das notify geändert wurde.
define notify_s0zaehler notify s0zaehler:.*-.* { \
So ich habe noch ein kleines Update .
Da ich jetzt ja problemlos alle meine Zähler in Fehm einlesen kann , geht es an die Feinkorrektur.
Zur Kontolle möchte ich mir die Zählerstände in FHEM anzeigen lassen.
Da ich über den S0 Bus nur Zählimpulse verarbeite muss ich einen Korrekturwert errechnen.
Sehr Hilfreich war nätürlich wie immer der Wikieintrag (http://www.fhemwiki.de/wiki/Stromz%C3%A4hler_und_1-Wire,_OWServer,_OWDevice)
Also als erste brauchen wir eine Feld um den Zählerstand ein zu tragen.
Das machen wir ganz einfach über ein Dummy:
define s0zaehler_offsetA dummy
attr s0zaehler_offsetA room Zaehler
attr s0zaehler_offsetA setList state:textField
attr s0zaehler_offsetA webCmd state
So jetzt soll ja nach der Eingabe des Aktuellen Zählerstandes der Korrekturwert berechnet werden.
Sobald man nach der Eingabe mit der Mouse ausserhalb des Eingabe Feldes drückt (Kein Enter zur Bestätigung) wird ein Notify ausgelößt :
define Func_SetOffsetA notify s0zaehler_offsetA { \
Jetzt ein bisschen Programmcode:
Die Variable "aufrufer_SetOffset" vorbereiten:
my $aufrufer_SetOffset = "@" ;;\
Auslesen und speichern der Zählimpulse und umrechnen in KWs (1000 Imp pro KW):
my $valueA = (ReadingsVal("s0zaehler","A",0)/1000 );;\
Jetzten den Eingabewert einlesen und die schon gezählten KWs abziehen:
my $setoffsetA = (ReadingsVal("s0zaehler_offsetA","state",0) - $valueA);;\
Dann das Ergebnis speichern:
{ \
Log 1, "Setze Zaehler A auf: $setoffsetA";; \
fhem("attr s0zaehler_offsetA $setoffsetA");;\
fhem("set s0zaehler_offsetA $setoffsetA");;\
} \
{ \
fhem("save");;\
}\
}
Jetzt steht der Korrekturwert im Eingabefeld.
So wir brauchen ein Dummy um den realen Zählerstand zu speichen und begrenzen ihn auf zwei Nachkomastellen:
define s0zaehler_ZaehlerA dummy
attr s0zaehler_ZaehlerA stateFormat {sprintf("%.2f KW ",ReadingsVal("s0zaehler_ZaehlerA","state",0) ) }
Gut jetzt zur Berechnung.Ich benutze dazu das Notify das ich auch zum loggen verwendet habe, also sobald beide Zählerstande sich geändert haben :
define notify_s0zaehler notify s0zaehler:.*-.* { \
Einlesen und speichern des Korrekturwertes :
my $ao= ReadingsVal("s0zaehler_offsetA","state",0) ;; \
Einlesen uns speichern der Zählimpulse mit der Umrechnung in KW:
my $a = ReadingsVal("s0zaehler","A",0)/1000 + $ao ;; \
Speichern des berechneten Zählerwertes im Dummy :
fhem ("set s0zaehler_ZaehlerA $a") ;; \
Klappt alles wunderbar.
Sollte es eine einfachere Lösung geben ,wäre ich für eine Anmerkung dankbar.
Hier der ganze Code:
#*********************Stromzähler S0*************************
define s0zaehler OW2S0SMSGUARD /dev/ttyUSB1 30
attr s0zaehler room Zaehler
attr s0zaehler stateFormat { sprintf("%.3f kWh %.3f kWh", ReadingsVal("s0zaehler","displayA","kWh"), ReadingsVal("s0zaehler","displayB","kWh"));; }
attr s0zaehler userReadings displayA {ReadingsVal("s0zaehler","A",0)/1000.0+AttrVal("s0zaehler","offsetA",0);;}, consumption_power1 differential {ReadingsVal("s0zaehler","A",0)*3600*0.001;;}, daily_power {ReadingsVal("s0zaehler","displayA",0)-Value("Dum_DP_Diff_D");;}, displayB {ReadingsVal("s0zaehler","B",0)/800.0+AttrVal("s0zaehler","offsetB",0);;}, consumption_power2 differential {ReadingsVal("s0zaehler","B",0)*3600*0.00125;;}, daily_power2 {ReadingsVal("s0zaehler","displayB",0)-Value("Dum_DG_Diff_D");;}
#z1 =1000/KWh
#z2 =800 /KWh
define s0zaehlera_momentanverbrauch readingsProxy s0zaehler
attr s0zaehlera_momentanverbrauch alias Stromverbrauch Einz.
attr s0zaehlera_momentanverbrauch room Energie
attr s0zaehlera_momentanverbrauch stateFormat {sprintf("%.0f W ",ReadingsVal("s0zaehler","consumption_power1",0)*1000) }
define s0zaehlerb_momentanverbrauch readingsProxy s0zaehler
attr s0zaehlerb_momentanverbrauch alias Stromverbrauch Ges.
attr s0zaehlerb_momentanverbrauch room Energie
attr s0zaehlerb_momentanverbrauch stateFormat {sprintf("%.0f W ",ReadingsVal("s0zaehler","consumption_power2",0)*1000) }
define FileLog_s0zaehler_a FileLog ./log/FileLog_s0zaehler_a-%Y-%m.log s0zaehlera_momentanverbrauch:stateFormat
#define s0zaehlerab dummy
define s0zaehler_ZaehlerA dummy
attr s0zaehler_ZaehlerA alias Schlafzimmer
attr s0zaehler_ZaehlerA room Energie,Zaehler
attr s0zaehler_ZaehlerA stateFormat {sprintf("%.2f KW ",ReadingsVal("s0zaehler_ZaehlerA","state",0) ) }
define s0zaehler_ZaehlerB dummy
attr s0zaehler_ZaehlerB alias Ges.Verbrauch
attr s0zaehler_ZaehlerB room Energie,Zaehler
attr s0zaehler_ZaehlerB stateFormat {sprintf("%.2f KW ",ReadingsVal("s0zaehler_ZaehlerB","state",0) ) }
define notify_s0zaehler notify s0zaehler:.*-.* { \
my $ao= ReadingsVal("s0zaehler_offsetA","state",0) ;; \
my $a = ReadingsVal("s0zaehler","A",0)/1000 + $ao ;; \
my $bo= ReadingsVal("s0zaehler_offsetB","state",0) ;; \
my $b = ReadingsVal("s0zaehler","B",0)/800 + $bo ;; \
my $text = "ZA:$a KWh, ZB:&b KWh" ;; \
fhem ("set s0zaehler_ZaehlerA $a") ;; \
fhem ("set s0zaehler_ZaehlerB $b") ;; \
fhem ("set s0zaehler $text") ;; \
\
}
define FileLog_s0zaehler_ab FileLog ./log/FileLog_s0zaehler_ab-%Y-%m.log s0zaehlerab
#****************Zählerstämde******************
# Dummys zum Eingeben der realen Zählerstände:
define s0zaehler_offsetA dummy
attr s0zaehler_offsetA alias Berechn. Offset A
attr s0zaehler_offsetA comment Eingabefeld für Zählerstand Strom zur Berechnung von "offsetA"
attr s0zaehler_offsetA room Zaehler
attr s0zaehler_offsetA setList state:textField
attr s0zaehler_offsetA webCmd state
# Funktion zum Berechnen und Setzen der Offset- Werte:
define Func_SetOffsetA notify s0zaehler_offsetA { \
\
my $aufrufer_SetOffset = "@" ;;\
my $valueA = (ReadingsVal("s0zaehler","A",0)/1000 );;\
my $setoffsetA = (ReadingsVal("s0zaehler_offsetA","state",0) - $valueA);;\
{ \
Log 1, "Setze Zaehler A auf: $setoffsetA";; \
fhem("attr s0zaehler_offsetA $setoffsetA");;\
fhem("set s0zaehler_offsetA $setoffsetA");;\
} \
{ \
fhem("save");;\
}\
}
attr Func_SetOffsetA group Berechnungen
#attr Func_SetOffsetA room Energie
define s0zaehler_offsetB dummy
attr s0zaehler_offsetB alias Berechn. Offset B
attr s0zaehler_offsetB comment Eingabefeld für Zählerstand Strom zur Berechnung von "offsetB"
attr s0zaehler_offsetB room Zaehler
attr s0zaehler_offsetB setList state:textField
attr s0zaehler_offsetB webCmd state
# Funktion zum Berechnen und Setzen der Offset- Werte:
define Func_SetOffsetB notify s0zaehler_offsetB { \
\
my $aufrufer_SetOffset = "@" ;;\
my $valueB = (ReadingsVal("s0zaehler","B",0)/800 );;\
my $setoffsetB = (ReadingsVal("s0zaehler_offsetB","state",0) - $valueB);;\
\
{ \
Log 1, "Setze Zaehler B auf: $setoffsetB";; \
fhem("attr s0zaehler_offsetB $setoffsetB");;\
fhem("set s0zaehler_offsetB $setoffsetB");;\
} \
{ \
fhem("save");;\
}\
}
attr Func_SetOffsetB group Berechnungen
#attr Func_SetOffsetB room Energie
Hallo,
ich versuche mich seit kurzem an SmartHome mit einem RasPi und fhem. Da ich meinen S0-Stromzähler mit fhem auslesen möchte, ist mir derzeit noch nicht klar ist, wozu ich überhaupt einen 1-wire Busmaster brauche, kommt mir der SMSGuard Stick doch recht gelegen, da er schon fix und fertig und recht günstig ist.
Darf ich mal fragen, wozu man den Busmaster ansonsten brauchen könnte? Wenn ich das im Forum richtig verstanden habe, dann das Auslesen/Zählen des S0 für 1-wire nicht ohne massive Bastelei möglich, da es keine günstige und fertige Counter gibt. Dafür fehlt mir leider die Zeit.
Mein Ziel ist, möglichst günstig, verlässlich und ohne große Bastelei die Zählerinfos in fhem mitschreiben zu können. Dazu scheint der SMSGuard doch optimal, oder?
Danke
Michael
Ist das nun eine Frage, oder eine Feststellung ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 03 Oktober 2015, 21:26:45
Ist das nun eine Frage, oder eine Feststellung ?
LG
pah
Naja, ich war kurz davor, den SMSGuard-Stick zu bestellen. Wenn es aber sinnvoller erscheint, irgendwas Bezahlbares und Verfügbares mit 1-wire umzusetzen, dann würde ich natürlich lieber das machen.
Wem sinnvoller erscheint ?
LG
pah
Es ist ganz einfach.
Für Leute ohne Erfahrung wenig Zeit und keine Bastelerfahrung ist das eine teure aber gute Alternative.
Du brauchst einen 1 Wire Busmaster um an deinen Raspberry den besagten 3 Leiterbus (manchmal auch nur 2 Leiter) an zu Schließen(der Raspberry kann auch einen Busmaster an seinen I/O Kanälen emulieren aber nur für 3,3V). Für den 1 W Bus gibt es dann Zählerbausteine, die die S0 Impulse zählen und die dann in FHEM ausgelesen , bearbeitet und angezeigt werden können.
Bei der hier beschriebenen Schaltung geht es recht einfach.
Anschließen und Läuft.
Alles laut Anleitung in FHEM einbinden und gut so.
Wenn man die Schaltung selbst baut, mag es für viele eine Sache der Ehre sein, aber halt nicht für jeden.
Zitat von: Joshibaer am 04 Oktober 2015, 11:49:42
Es ist ganz einfach.
...
Bei der hier beschriebenen Schaltung geht es recht einfach.
Anschließen und Läuft.
Alles laut Anleitung in FHEM einbinden und gut so.
Wenn man die Schaltung selbst baut, mag es für viele eine Sache der Ehre sein, aber halt nicht für jeden.
Alles klar. Da ich derzeit noch keine weitere Verwendung für 1-wire bei mir sehe - ich kann nachträglich eh keinen Bus mehr durchs ganze Haus legen- werde ich mir den Stick wohl kaufen und damit meinen Zähler auslesen. Dummerweise habe ich in Unkenntnis der Möglichkeiten einen einfachen mit S0-Bus bekauft. Jetzt hab ich gesehen, dass es auch welche gibt, die über ein Modbus-Protokoll noch mehr Daten rausgeben und nicht wirklich teurer gewesen wären. Naja, erstmal sollte es per S0 reichen. Ist schon echt verwirrend, was es so alles auf dem Markt gibt.
Danke jedenfalls!
Es ist (gerade für einen Anfänger !) absoluter Unsinn, einen Zähler mit Modbus zu betreiben. Alle Informationen, die man braucht, kann man problemlos aus dem Mitlesen der S0-Daten erhalten: Leistung, Leistungspitzen, durchschnittliche Leistung, Gesamtenergie etc. ergeben sich aus der Verfolgung der Impulse. Allenfalls solche Daten wie gegenwärtige Spannung, Frequenz und Phasenfehler könnte man noch messen - aber zu welchem Zweck bitte ?
Die Smart Meter mit Modbus (und anderen...) Interfaces sind in der Regel vollständig übertechnisiert, sie stellen deshalb ein nicht unerhebliches Sicherheitsrisiko für unsere gesamte Infrastruktur dar.
Im Übrigen ist es auch Unsinn, dass man für 1-Wire ein Kabel durchs ganze Haus ziehen muss - das geht auch anders
http://www.fhemwiki.de/wiki/1W-IF-WIFI
oder,mit einem anderen Ansatz:
http://www.instructables.com/id/Low-cost-WIFI-temperature-data-logger-based-on-ESP/
http://iot-playground.com/2-uncategorised/41-esp8266-ds18b20-temperature-sensor-arduino-ide
LG
pah
Hallo,ich bin auch noch neu in sachen FHEM.Ich hab nun den oben besagten USB Master und der funktioniert in FHEM auf einem Raspberry PI3 auch wirklich gut.Nun zu meiner Frage.Hat einer von euch schon den Temperatur/Feuchte Sensor DHT22 einbinden können?Wenn ja wie habt ihr das geschafft.
Der DHT22 hat kein Interface für den 1-Wire Bus. Würde mich äußerst erstaunen, wenn den jemand auf dem 1-Wire Bus zum Laufen bekäme.
LG
pah
Hallo,
danke für diese Anleitung. Leider bekomme ich folgenden Fehler im Log.
2016.12.08 16:39:32 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at (eval 5499) line 1.
2016.12.08 16:39:32 3: eval: {ReadingsVal("s0zaehler","displayA",0)-Value("Dum_DP_Diff_D");}
2016.12.08 16:39:32 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at (eval 5500) line 1.
2016.12.08 16:39:32 3: eval: {ReadingsVal("s0zaehler","displayB",0)-Value("Dum_DG_Diff_D");}
2016.12.08 16:39:32 3: set s0zaehler ZA:18452.82 KWh, ZB:&b KWh : Unknown argument ZA:18452.82, choose one of S0-reset:noArg interval reset:noArg
2016.12.08 16:39:32 3: notify_s0zaehler return value: Unknown argument ZA:18452.82, choose one of S0-reset:noArg interval reset:noArg
Woran könnte das liegen? Vielen Dank für die Hilfe.
vg
Andreas
Hi,
ich habe den USB Master ebenfalls von SMS Guard gekauft und mit den beiden Modulen hier aus dem Thread läuft das ohne Probleme. Danke für die Umsetzung !
Mein Anwendungsfall ist aber auch vergleichsweise einfach: ich will meine Heizung einfach mit maximal vielen DS18B20 Sensoren durch munitionieren. Und dafür ist dieser USB Adapter und die Module genau richtig.
Wenn ich mir aber den Thread hier so durchlese, hätte ich mich vielleicht vor dem Kauf mal besser informieren sollen. Aber geht ja jetzt.
Hallo,
der Thread ist ja schon etwas älter und der letzte Stand der beiden Module ist von Mitte 2015. In svn habe ich die Dateien nicht gefunden.
Hat jemand daran weiter entwickelt? Gibt es einen neueren Stand?
Gruß
FillyFairy
ich habe einfach die beiden Dateien aus diesem Post hier im Fred genommen
https://forum.fhem.de/index.php/topic,28447.msg320488.html#msg320488 (https://forum.fhem.de/index.php/topic,28447.msg320488.html#msg320488)
Sind aus August 2015 aber geht.
Vielen Dank für die schönen Module! :)
Mein Beweggrund war ein S0-Zähler ohne große Bastelei, vom eigentlich Pi unabhängig (reboot, updates, etc.) und da kam das Gerät von SMS-Guard passend. Ich habe auch keine finanziell günstigere Lösung finden können. Es funktioniert mit aktuellem Raspbian auf Raspberry 3 tadellos. Anstecken, die zwei Dateien für fhem ablegen, fhem neu starten und define. Viel einfacher kann ich es mir nicht vorstellen.
Einziger Verbesserungswunsch: neben S0_reset (auf Null) noch ein S0_set (auf beliebigen Wert). Dann spart man sich ein userreadings, was nun aber auch kein Hexenwerk ist
Hallo zusammen,
ich habe das Problem, dass das Modul bei einem Neustart immer das gesetzte Intervall "vergisst". Ich habe im Quellcode die Stelle nicht gefunden, wo ich das Standardintervall einstellen kann.
Vielleicht könnt ihr mir ja weiterhelfen?
Danke! :)
Zitatset usbmaster interval xx
oder
Zitatattr usbmaster interval xx
hast du mit deiner gewünschten Intervalldauer in Sekunden anstelle der "xx" schon probiert? Bei mir steht dieses auf 10 Sekunden und ich nutze "event-on-change-reading"...
Grüße
Hallo,
wurde das Modul noch mal aktualisiert? Es läuft bei mir seit über 2 Jahren recht stabil. Dabei nutze ich einen Zählereingang (Gaszähler) und vier Temperatursensoren (Heizungsvorlauf) am 1-wire-Bus.
Was mir aufgefallen ist, nach einigen Wochen Laufzeit sammeln sich Interns mit "kryptischen" Zeichen an, also nicht klar "OW-Dev0, 1, 2" etc. bezeichnet.
PERL WARNING: Argument "��M-^\M-^\����0" isn't numeric in addition (+) at ./FHEM/00_OW2S0SMSGUARD.pm line 291.
Das tut der Funktion prinzipiell keinen Abbruch.
* Eine Verbesserung wäre, einfach zu prüfen, ob es sich bei einer neuen Device-Bezeichnung um einen Integer handel.
Nun habe ich einige DS2401 angeschlossen, die werden auch zuverlässig erkannt, aber mehr passiert nicht.
* Eine Verbesserung wäre, wenn neu Geräte ein entsprechendes Reading erzeugen habe ich als user Reading nachtgerüstet, nach dem Schema:
[quote]userReadings dev1 { InternalVal($NAME,"OW-Dev1","") }[/quote]
Ziel der DS2401 ist einfache Zustände (Statusmeldungen der Heizung, Rauchmelder, etc.) "abzugreifen". Dazu ist es irrelevant, welche Geräte-Nummer es am Bus ist, sondern nur die ID.
Leider kommt (mit verbose 2 abstellbar) noch Fehlermeldungen im Log (usbmaster NOK message):
2021.01.24 23:39:10 5: SimpleWrite: $4
2021.01.24 23:39:10 5: OW2S0SMSGUARD (ReadAnswer): 4;n;FF;FF;FF;FF;FF;FF;F
2021.01.24 23:39:10 5: OW2S0SMSGUARD (ReadAnswer): F;FF;FF;F7;
2021.01.24 23:39:10 5: usbmaster Parse: 4;n;FF;FF;FF;FF;FF;FF;FF;FF;FF;F7;
2021.01.24 23:39:10 3: usbmaster NOK message: 4;n;FF;FF;FF;FF;FF;FF;FF;FF;FF;F7;
* Kann man diese gefahrlos auch als "ok" erkennen oder habe ich noch ein Problemchen in der Installation vielleicht?
Grüße
Zitat von: Jostar am 25 Januar 2021, 10:01:05
wurde das Modul noch mal aktualisiert?
Zumindest nicht von mir, die Namen in deinem Log deuten ja auch auf die Version von NIE! August 2015 hin.
Aktiv habe ich die Hardware nicht mehr in Einsatz seit der Stromzähler mit dem S0 Ausgang vor ca vier Jahren entfallen ist.
Ich müsste morgen mal meine Bastelkiste durchsuchen ob ich das Ding noch finde, denn eine neue Einsatzidee hätte ich wieder.
Bei der Gelegenheit könnte man dann auch gleich ein paar Jugendsünden (Prototypen, perlcritic) in dem Modul ausbessern.
Ich habe das Ding wiedergefunden und es scheint auch noch zu funktionieren ..... das war die gute Nachricht.
Die schlechten :
Den Hersteller finde ich nicht mehr, d.h. neue User wird es dann wohl kam geben.
Als ich den Code durchgelesen habe war ich doch erstaunt wie wenig Ahnung ich vor sechs Jahren von FHEM hatte und warum ich das so umständlich umgesetzt habe. Ein zweistufiges Modul ist absolut unnötig, da von der FW eh nur Temp Sensoren unterstützt werden könnten die auch gleich als Readings gelistet werden.
@Jostar, mit deinen DS2401 musst du mir mal geistig auf die Spünge helfen. Jeder Chip hat zu seiner ID als Nutzdaten eine eindeutige Nummer ?
Die ID kann die FW auslesen aber mit den Nutzdaten wohl nichts anfangen ? ( die FF Blöcke im Log )
Nun die Frage : Wozu schliesst man so einen oder gar mehrere davon an einen Bus ?
Meines Wissens ist der DS2401 robust und günstig (in Anschaffung und Betrieb). Man kann damit (also 10 Stück) zum Beispiel den Status aller Kellerfenster leicht abfragen, muss nur ein Bus verlegen und braucht 10 Reed-Sensoren. Dann gibt es noch die Möglichkeit den Bus zu überwachen:
a) Nachricht wenn ein neuer Teilnehmer hinzukommt (Nachteil, in dem kurzen Moment ist der Busmaster blind, könnte ggf. für kurze Zeit eine andere Nachricht nicht empfangen)
b) Nachricht wenn ein bestehender Teilnehmer verschwindet (aus meiner Sicht keine Nachteile, der dauernde Stromverbrauch ist minimal)
Der Vorteil von der SMSGUARD-Lösung: nun ja, einfach an USB anschließen, keine extra Spannungsversorgung. Shop scheint noch online:
https://www.sms-guard.org/shop.php
ok, .org statt .de und das Ding gibt es noch sowie die Anleitung. Die FW wurde von 2014 bis 2020 auch erweitert.
Sorry, aber ich habe es mit den DS2401 noch immer nicht begriffen. Der Reed schaltet die Datenleitung ?
So das die Teilnehmer am Bus kommen und gehen ? das muß dann aber Einfluß auf die laufende Nr haben ?
ZitatNun die Frage : Wozu schliesst man so einen oder gar mehrere davon an einen Bus
Da oder nicht da. Nimm Reed-Öffner (Fenster zu - 1-Wire NICHT am Bus). Taktzeit auf dem Bus 250ms. Wenn ein Fenster geöffnet wird, wird dieser DS2401 erkannt. Die Nummer==ID ist eindeutig dem Fenster zugeordnet.
LG
pah
Ja, genau so geht es. Aber ganz richtig auch der Kommentar weiter oben, die device-ID ist nicht relevat. Ich habe es jetzt so gelöst:
Modul gibt als userreading in der "dev1" die Geräte "id". Darauf lauscht ein notify:
usbmaster:(dev\d):.* {
if ($EVENT) {
Log3 $NAME, 3, "[$SELF] Device $NAME wurde behandelt ($EVENT)";
}
if ($EVTPART0 ne substr($EVENT, 0, -1)) {
fhem("setreading $SELF ".substr($EVTPART0, 0, -1)." ".(split(" ", $EVENT))[1]);
fhem("defmod id".(split(" ", $EVENT))[1]." dummy");
fhem("setreading id".(split(" ", $EVENT))[1]." id ".substr($EVTPART0, 0, -1));
} else {
#gerät ist nicht mehr am Bus
fhem("defmod id".ReadingsVal($SELF,substr($EVTPART0, 0, -1),0)." dummy");
fhem("setreading id".ReadingsVal($SELF,substr($EVTPART0, 0, -1),0)." id gone");
fhem("setreading $SELF ".substr($EVTPART0, 0, -1)." 0");
Log3 $NAME, 3, "[$SELF] Device $NAME ist verschwunden ($EVENT)";
}
#brauchen wir nicht mehr, macht das Gerät usbmaster nun selber
#delete($defs{$NAME}{dev4});
}
Je nach "id" werden Dummies angelegt bzw. bekommen ein reading verpasst. Auf dass kann ich meine Aktionen dann triggern. In dem Kommentar oben steht es noch, ein Problem war mit verschwindenden Geräten umzugehen. Dass geht prinzipiell auch im notify, habe ich aber im Modul gelöst (sehr brutal, weiß ich).
Ich habe einfach eine Zeile eingefügt, die alle Internals "dev0, 1, ..." löscht, sobald sich die Anzahl ändert ("devquantity"). Ich frage aktuell alle 10 s ab, 250 ms müsste ich testen, hat in meiner Anwendung erst mal keine Notwendigkeit.
Test geht auch mit Interval 0.25 ... allerdings habe ich zwei Dinge festgestellt:
1. es kommen doppelte Werte (in der gleichen Sekunde), so dass die Ablehnung aus meiner mySQL-Datenbank im log erscheint
2. OW2S0SLAVE scheint nicht dass Attribut "event-on-change-reading temperature:0.5" auszuwerten, es "feuert" munter weiter
2021.01.28 23:33:10 3: DbLog logdb -> Insert into history rejected (possible PK violation) - TS: 2021-01-28 23:32:44, Device: Stubenfussbodenrechts, Event: temperature: 29
2021.01.28 23:33:10 3: DbLog logdb -> INFO - 6 of 7 events inserted into table history due to PK on columns TIMESTAMP,DEVICE,READING
2021.01.28 23:33:40 3: DbLog logdb -> Insert into history rejected (possible PK violation) - TS: 2021-01-28 23:33:31, Device: Stubenfussbodenrechtsp, Event: temperature: 27.4
2021.01.28 23:33:40 3: DbLog logdb -> INFO - 2 of 3 events inserted into table history due to PK on columns TIMESTAMP,DEVICE,READING
2021.01.28 23:34:10 3: DbLog logdb -> Insert into history rejected (possible PK violation) - TS: 2021-01-28 23:34:06, Device: Stubenfussbodenrechtsp, Event: temperature: 27.4
2021.01.28 23:34:10 3: DbLog logdb -> INFO - 3 of 4 events inserted into table history due to PK on columns TIMESTAMP,DEVICE,READING
2021.01.28 23:34:40 3: DbLog logdb -> Insert into history rejected (possible PK violation) - TS: 2021-01-28 23:34:29, Device: Stubenfussbodenrechtsp, Event: temperature: 27.4
2021.01.28 23:34:40 3: DbLog logdb -> INFO - 5 of 6 events inserted into table history due to PK on columns TIMESTAMP,DEVICE,READING
Wie gesagt, bin natürlich sehr interessiert es direkt und vor allem deutlich besser im Modul zu lösen!
Falls es hilft, so sieht es im Eventlog aus, wenn ein DS2401 (01E5D9370B00005D) als 6. Gerät am Bus "kommt" und nach ca. 5 s wieder "geht":
2021-01-28 23:51:07 OW2S0SLAVE Stubenfussbodenrechtsp temperature: 27
2021-01-28 23:51:13 DbLog logdb background_processing_time: 0.0999
2021-01-28 23:51:13 DbLog logdb sql_processing_time: 0.0585
2021-01-28 23:51:28 notify notify_usbmaster dev5: 01E5D9370B00005D
2021-01-28 23:51:28 Global global MODIFIED id01E5D9370B00005D
2021-01-28 23:51:28 dummy id01E5D9370B00005D id: dev5
2021-01-28 23:51:28 OW2S0SMSGUARD usbmaster dev5: 01E5D9370B00005D => OK
2021-01-28 23:51:28 OW2S0SMSGUARD usbmaster devquantity: 6
2021-01-28 23:51:43 DbLog logdb background_processing_time: 0.1522
2021-01-28 23:51:43 DbLog logdb sql_processing_time: 0.1087
2021-01-28 23:51:44 Global global MODIFIED id01E5D9370B00005D
2021-01-28 23:51:44 dummy id01E5D9370B00005D id: gone
2021-01-28 23:51:44 notify notify_usbmaster dev5: 0
2021-01-28 23:51:44 OW2S0SMSGUARD usbmaster dev5:
2021-01-28 23:51:44 OW2S0SMSGUARD usbmaster devquantity: 5
2021-01-28 23:52:14 DbLog logdb background_processing_time: 0.4984
2021-01-28 23:52:14 DbLog logdb sql_processing_time: 0.4565
2021-01-28 23:52:33 OW2S0SLAVE Stubenfussbodenrechtsp temperature: 26.9
"Defmod" sollte ich vielleicht umbauen zu einem "define" nur wenn es das Device noch nicht gibt?
Die von pah genannten 250ms beziehen sich auf den 1W Bus, nicht auf das Intervall zum Abfragen des Device.
Laut deren Doku https://www.sms-guard.org/downloads/1wire-USB-Master.pdf können die Teilnehmer Sensoren erst 1 Sekunde nach dem eintreffen der $? Antwort abgefragt werden. Daher würde ich je nach Anzahl der Temperatur Sensoren am Bus kein Intervall kleiner als 10 Sekunden wählen.
Ich hatte nur noch einen DS1820 in der Kiste und habe gestern auch einen DS2401 bekommen.
Das Modul habe ich jetzt fast komplett neu geschrieben, da mir einiges an der alten Version nicht gefallen hat und die saubere Integration der DS2401 doch etwas aufwendiger war als gedacht. Im Anhang mein Vorschlag wie das Modul heute ausschauen müsste.
Es wird keine Slave Device mehr erzeugt, (und Dummys sind eh ein nogo .. ) alle OW Teilnehmer sind Readings direkt im Device.
Die DS2401 haben als Wert absent oder present, DS18xx ihren aktuellen Temperaturwert.
Da die IDs als als nackte Readings etwas unschön sind, hat das Modul ein neues Attribut map_OWIDs bekommen.
Damit können die abstrackten IDs direkt in sprechende Namen überführt werden , Bsp :
attr <name> map_OWIDs 10D64CBF02080077=Keller,018468411C0000BA=TestDS
ToDo : bei den DS2401 muß bei FHEM Neustart unbedingt noch der interne Hash restauriert werden, da sonst DS2401 die zuletzt den Status present hatten und direkt nach Neustart nicht aktiv am Bus hängen ihren Status nicht aktualisieren ($? listet sie ja nicht)
Guten Abend,
das sind gute Nachrichten! Ich habe das Update eben ausprobiert:
1. neue 00_OW2S0SMSGUARD.pm runtergeladen und überschrieben
2. reload 00_OW2S0SMSGUARD.pm -> keine Einträge im Log
3. Es erscheinen neue Reading, für die angeschlossenen 5 Geräte in meinem Fall (siehe Anhang), in der alten Version waren das Internals
4. Es kommen keine Werte
5. get usbmaster OWdevicelist -> fhem stürzt ab, im log:
2021.01.30 21:14:06 1: PERL WARNING: Argument "_98_statistics" isn't numeric in int at ./FHEM/00_OW2S0SMSGUARD.pm line 253.
Can't use string ("Statistik_Strom") as a HASH ref while "strict refs" in use at ./FHEM/00_OW2S0SMSGUARD.pm line 254.Eine Statistic lief bei mir auf dem Reading "total", dass A zu einem Abase addiert:
total:A.* { ReadingsNum($NAME,"Abase",0)+ReadingsNum($NAME,"A",1)/100 }6. manueller Neustart fhem, keine Verbesserungen
7. bestehendes Gerät deaktiviert (attr usbmaster disable 1)
8. neues Gerät angelegt (define usbmaster2 OW2S0SMSGUARD /dev/ttyUSB0@38400)
9. passiert genau nix, auch keine Readings
10. get usbmaster2 OWdevicelist --> popup "Sorry, no OW devices found !"
11. attr usbmaster 2 verbose 0, shutdown+restart
12. readings sind erstellt, wieder nur eins, siehe Anhang smsguard2.PNG
Was muss ich tun, um das Modul in Betrieb zu nehmen? Ich habe keine Idee mehr.
Grüße!
PS: Warum sind "Dummys ein no go"? Dabei finde ich diese oder eine Aufsplittung in "Slaves" (analog Hue Modul) ganz praktisch, hat den Vorteil im dblog steht:
TIMESTAMP | DEVICE | TYPE | EVENT | READING | VALUE | UNIT |
| 2021-01-30 21:13:38 | Stubenfussbodenrechts | OW2S0SLAVE | temperature: 31.1 | temperature | 31.1 | °C |
Nach dem neuen "Modell", würde ja nur stehen:
TIMESTAMP | DEVICE | TYPE | EVENT | READING | VALUE | UNIT |
| 2021-01-30 21:13:38 | usbmaster2 | OW2S0SMSGUARD | Stubenfussbodenrechts: temperature 31.1 | temperature | 31.1 | °C |
PPS: Ich habe mal versucht die Infos zusammenzutragen und ins wiki gestellt. Passt das @Wzut inbesondere?
Ok unschön ... aber das wird :)
Deine Punkte 1 - 5
Das musste schief gehen, sorry mein Fehler. Nach dem ersetzen des Moduls musste FHEM unbedingt neu gestartet werden, ein einfaches reload konnte nicht gehen. Sorry hatte ich nicht geschrieben.
7-9 :
Dann hast du zwei Geräte die auf die gleiche USB Schnittstelle zugreifen wollen. Würde ich erst einmal so nicht machen.
Ein Device reicht. Wenn dieses nicht anläuft oder den Betrieb einstellt (Eventmonitor) zuerst das set Kommando reset versuchen.
11 : wieso nur eins ? ich sehe da 4 x DS18B20 und einen DS2401
Was bei dir schief geht ist die Abfrage der Temperatur Werte , daher das ? . Wobei im Log mit verbose 4 oder 5 würde man vermutlich sehen das sie kommen, aber ein saublöder Tippfehler verhindert das sie decodiert werden .... :(
Schau bitte im Modul nach diese Zeile :
$hash->{helper}{$num}{typ} = 'DS1B820' if ($model == 28);ich musste auch zweimal hinschauen -> DS1
B820 und später wird aber richtig auf DS1
8B20 geprüft.
D.h wenn du diesen Dreher ausbesserst sollten deine Temperatur Werte richtig decodiert werden. (diesmal reicht reload)
Falls dann immer noch keine Werte kommen stell bitte das Device auf verbose 5 und poste das Log.
ZitatWarum sind "Dummys ein no go"?
weil es fast keine Fälle gibt wo man diese Konstruktion wirklich braucht. Die User wissen es halt oft nicht besser und wenn Anfänger A von Dummy User B abschreibt setzt sich das immer weiter fest das man ständig für jede Kleinigkeit einen Dummy braucht.
Wenn man z.b einen Dummy nur anlegt um ein Reading aus einem Device rauszulösen und in FHEMWEB extra darzustellen : readingsProxy oder readingsGroup. In vielen anderen Fällen tut es fast immer ein simples userreading. Aber ok ist meine Meinung der User kann natürlich machen was er will, FHEM ist ein freies Land :)
Was die Einträge in DbLog betrifft : es ist doch vollkommen wurscht wie eine Information in der DB steht, wichtig ist doch das sie drin ist.
Was machst du später mit dem Wert ? in 99% aller Fälle doch nur ein SVG, oder ?
Zitatund ins wiki gestellt
welches Wiki ? Bitte ein Link
Thema Screenshots : Bitte keine Screenshots , alles was wichtig ist steht i.d.R. entweder im list oder im Log (mit entsprechendem verbose Level erstellt) und den Umweg ein list in eine txt zu packen kann man sich auch sparen, packe die Info einfach direkt in Code Tags, liest sich schneller und einfacher.
Vielen Dank für die Hinweise.
Mit wiki meine ich natürlich das fhem wiki, der Link wäre natürlich besser gewesen anzugeben, die Seite ist https://wiki.fhem.de/wiki/OW2S0SMSGUARD
1. Zeile 290 abgeändert
- $hash->{helper}{$num}{typ} = 'DS1B820' if ($model == 28);
+ $hash->{helper}{$num}{typ} = 'DS18B20' if ($model == 28);
2. fhem shutdown+restart
3. Temperaturmeldungen erscheinen
4. Logmeldungen im Gerät festgelegt (attr usbmaster verbose 3) --> keine Einträge
6. DS2401 hinzugenommen, abgeklemmt, --> funktioniert bestens
5. Logmeldungen im Gerät festgelegt (attr usbmaster verbose 5) --> viele Einträge mit Details
Sauber, würde ich sagen!
Nun zur Anschlussverwendbarkeit.
1. Kann mann die Dev-Ausgaben wieder aktivieren? Zum Beispiel wenn gesetzt ist:
oldreadings dev.
Dann würde ein kompatibler Betrieb ohne jede Änderung weiterhin möglich sein. Das "Mapping" vom Internal auf Reading könnte natürlich auch das Modul erledigen, ich hatte das so gelöst (natürlich unflexibel, für dev0...5):
dev0 { InternalVal($NAME,"OW-Dev0","") }
2. Kann man die IDs wieder sichtbar machen?
3. Kann man die Fehlertolleranz erhöhen? Also konkret, Reaktion wenn gar keine Geräte-ID in der Form eines Integers gemeldet wird.
PERL WARNING: Argument "^Y���4592180267" isn't numeric in int at ./FHEM/00_OW2S0SMSGUARD.pm line 361.
hatte ich vermieden
if (defined($linearr[2]))
287 {
+288 if (length($linearr[2]) == 16 && looks_like_number($linearr[0]))
+289 {
290 my $ok = ($linearr[1] eq "o") ? "OK" : "NOK";
+299 }
Das benötigte aber aber auch ein zusätzliches Paket:
+9 use Scalar::Util qw(looks_like_number);
4. Vielleicht auch noch mal reflektieren, ob die Ablage in Readings nicht ungünstig ist.
* Im vorliegenden Fall muss entweder die "10D64CBF02080077" oder eben "Keller" in die dblog Regex händisch aufgenommen werden, um überhaupt geloggt zu werden.
* Mit extra Geräten gibt man sich wieder mehr Möglichkeiten als nur 1 reading zu haben. So kann Keller eine Temperatur haben (Reading "temperature", ein Reading "present", und weitere Readings (z.B. Durchschnitts und Extremwerte für die Temperatur) die generisch gebildet werden (via "statistics" Modul). Die Zählerstände nicht zu vergessen.
5. bei einem Neustart feuern die neuen Readings erst mal ein unbekannt, also "019AD4380B000097 unkown"
6. im Gegensatz zur alten Version aktualisieren sich die Readings im Browser erst bei F5, also werden nicht mehr automatisch rot eingefärbt und zeigen die Änderungen. Ich habe keine Ahnung, woran das liegen könnte.
Zitat1. Kann mann die Dev-Ausgaben wieder aktivieren?
Done
Zitat2. Kann man die IDs wieder sichtbar machen?
Wo ? die stehen doch als Value bei OW-Dev
Zitat3. Kann man die Fehlertolleranz erhöhen?
Na klar kann man :) looks_like_number ist eine saubere Sache -> done
Aber dann sollte man auch den nächsten Schritt machen und die Counter Werte ebenfalls prüfen -> done
Bleibt als ToDo noch die CRC Prüfung ->
Zitatdas 10.Byte ist eine Checksumme für die serielle Übertragung (Byte1-9 aufaddiert)
Zitat4. Vielleicht auch noch mal reflektieren, ob die Ablage in Readings nicht ungünstig
Nun das liegt an dir mich mit guten Argumenten zu überzeugen :)
- DbLog lass ich nicht gelten, denn egal was geloggt werden soll, es ist immer eine RegEx notwendig die "greift" ob die nun auf ein Reading eines Devices matched oder auf ein komplettes Device. Oder wenwendest du mehrere defines von DbLog mit unterschiedlichen Filtern ?
Hast du dir mal readingsProxy angeschaut und damit gespielt ? Das Ding macht out-of-the-box das was vorher USBSLAVE machte und noch einiges mehr. Wenn es bereits ein FHEM Modul zur Lösung einer Aufgabe gibt, dann nutzt man es und wirft nicht noch ein anderes schlechteres in Rennen.
Zitat5. bei einem Neustart feuern die neuen Readings erst mal ein unbekannt, also "019AD4380B000097 unkown"
Das stimmt so nicht:
a. verwende ich extra setReadingsVal statt readingsSingle/BulkUpdate um das Auslösen (feuern) eines Events zu verhindern
und b. betrifft das nur die DS2401, denn wie ich bereits schrieb ist beim FHEM Neustart noch unklar ob der gerade am Bus hängt und der restaurierte Status mittels fhem.save überhaupt richtig ist.
Zitat6. im Gegensatz zur alten Version aktualisieren sich die Readings im Browser erst bei F5
das muß aber eine andere Ursache bei dir haben, ich verwende nach wie vor readingsEndUpdate ,1 um Events zu erzeugen die FHEMWEB dann in die roten Readings umsetzt (natürlich abhängig von den gesetzten event-on Attributen) Für FHEMWEB ist entscheident wie unter dem FHEMWEB Device das Attribut longpoll gesetzt ist -> i.d.R heute websocket.
Ich habe die Version im Posting #62 gegen die aktuelle ausgetauscht.
Das klingt seht gut.
Nr. 1 Die Änderung in den Internals
früher: OW-Dev0 2832AD4592100214 => OK
jetzt: OW-Dev0 2832AD4592100214 => 1
Verstehe ich soweit. Hat das "NIO" (früher), "0" (heute) ausgesagt, dass die Checksumme nicht stimmte?
Nr. 2 Mit "IDs" meinte ich die "Bus-ID". Aber klar, wenn die wieder in den Internals sind, baue ich die via userreadings zusammen (Wieder ein Argument, warum ein Device pro DS2401 etc. sinnvoll ist, es hat das Reading für Temperatur, ID am Bus, Status, etc. aber das gehört zu Abschnitt 4)
Nr. 3 Erhöhte Fehlertolleranz
"Bleibt als ToDo noch die CRC Prüfung ->"
ist hier offen ein "looks_like_number" oder überhaupt diese auszuwerten?
Nr. 4 Separate Readings
Hier hatte ich ja schon Argumente gebracht:
aber vielleicht noch mal anschaulich, am use case, dem hinzufügen eines neuen Busteilnehmers
Argument 1:
Aktuelle Lösung: es gibt ein neues Reading mit neuem Namen, um dessen Wert als Event zu feuern muss ich händisch "event-on-change" anpassen, um den Wert in meine mysqk-Datenbank zu bekommen, muss ich überdies den Namen des neuen Readings in die Regex der dblog aufnehmen.
Alte Lösung: es gab ein neues OWSLAVE, mit dem Reading "temperatur". Da ja schon "temperatur" im dblog für andere Sensoren steht, ist nichts manuell noch anzupassen</code>
Argument 2:
Aktuelle Lösung: es gibt ein Reading das so heißt wie der Busteilnehmer. Davon nun min/max/avg, etc. Werte automatisch zu bilder, erfordert eine Anpassung im Statistic-Modul.
Alte Lösung: mit extra Geräten pro Busteilnehmer gibt man sich wieder mehr Möglichkeiten als nur 1 reading zu haben. So kann "Keller" eine Temperatur haben (Reading "temperature"), ein Reading "present", und weitere Readings (z.B. Durchschnitts und Extremwerte für die Temperatur) die generisch gebildet werden (via "statistics" Modul). Die Zählerstände nicht zu vergessen.
Argument 3:
Alte Lösung: Die Ablage der Daten in der mySQL-Tabelle bleibt lesbar. Da wo Reading drüber steht, ist auch reading drin.
Argument 4:
Alte Lösung: Ergänzt man zum Beispiel Readings mit Einheiten, so klappt das prima anhand des Readingnamen (z.B. temperatur).
Neue Lösung: Soll nur auch "°C" ans Reading "019AD4380B000097" oder "Keller" muss man das umständlich nachpflegen.
Argument 5:
Neue Lösung: Wenn man regelmäßig die Messwerte in der Datenbank reduziert, also via dblog oder dbrep, so sind die Befehle kaum vergleichbar.
Alte Lösung: Normalerweise reduziert man die Readings "temperatur" und bei device usb-Master sind es viele spezielle Namen, nämlich für jeden Busteilnehmer.
Nr 6. war ich dämlich. Musste natürlich ein event-on-update auf die gemappten Namen machen, nun werden die auch wieder "rot" (Haken dran)
Nr. 7 (neu) Auffälligkeiten zu den Busteilnehmern
In der Lösung alt, bin ich ja über "dev1" (geprüft auf integer) zu einem eindeutigen Device (id gefolgt von der Geräte-ID) gekommen. Hier gab es die letzten Tage keine Probleme. Heute allerdings habe ich schon mehr Geräte im Modul als am Bus:
id019AD4380B000097 ???
id2803DC4592150261 ???
id2803DC4592150291 T: 27.3 (0 min alt)
id28069D45921802D7 T: 27.3 (0 min alt)
id2832AD4592100214 T: 28.2 (0 min alt)
id2846794518180267 ???
id2846794592180267 T: 28.6 (0 min alt)
"Echte" Geräte haben auch eine Temperatur. Auffällig sind die "???"-Geräte nur eine Ziffer Abweichung in der ID. Ist das Zufall (durch vielleicht häufigere reboots von fhem)? Vielleicht ergibt sich das Problem ja durch Auswertung der Checksumme. Ich lasse mal alles weiter laufen, mal schauen ob stabil ohne weitere "neue" Geräte läuft.
Nr. 8 (neu) Verwendung Repository
Gibt es eigentlich einen Grund, warum das Modul nicht im normalen update war/ist, also eingecheckt?
1. ja 0 = NOK , 1 = OK
2. Verstehe ich nicht, was muß da zusammengebaut werden ?
3. CRC Prüfung habe ich jetzt drin, allerdings gibt es eine Checksumme nur im Telegramm mit den gelesenen werten der Temperatur Sensoren ( $0 .. $63). Beim Status ($?) gibt es keinerlei Prüfungen. looks_like_number nutze ich zur Kontrolle der Bus ID 0..63 und für die beiden S0 Zähler A & B
4. Lass uns bitte mal Problem/Bug und nice-to-have trennen, zumindest solange bis du auf meine Fragen antwortest oder mal einen Versuch mit readingsProxy gemacht hast.
7. Wie wird diese Art der Ausgabe erzeugt ? Was die drei Fragezeichen bedeuten vermutlich keinen Temperaturwert ?
id019AD4380B000097 ??? , das ist wohl ein DS2401 udn der wird auch nie einen haben. Warum übernimmst du nicht das vorhandne present/absent ?
id2803DC4592150261 ???
id2803DC4592150291 T: 27.3 (0 min alt)
----------------------
id2846794518180267 ???
id2846794592180267 T: 28.6 (0 min alt)
Beim ersten Paar hätte ich noch gesagt ist aus der gleichen Charge und nah an seinem Bruder, aber das zweite Paar hat zwei Stellen Abweichung in der Mitte ... sehr komisch. Aber wie bereits oben geschrieben gibt das Statustelegramm keinerlei Prüfungen her. Die einzige heutige Prüfung ist die auf die Länge 16 Byte , d.h. selbst wenn man da jetzt noch zusätzlich auf 0-9|A-F prüft geht der offensichtlich falsche 2846794518180267 da glatt durch :(
8. Für mich war das Modul damals nie wirklich fertig und mit gefährlichen Halbwissen aus anderen Modulen zusammenkopiert.
U.a. wäre ein einchecken ohne command.ref auch nicht möglich gewesen. Mal schauen wenn nun schön wird werd ich es zumindest unter contrib legen.
Guten Abend, danke für die Antworten.
zu 2. Mein Ziel ist ein Gerät mit dem Reading "Bus-ID" (also 0,1,2,...). Aktuell "schiebe" ich die Info via notify vom OW2S0SMSGUARD reading in dummys. Ich denke, dass kann auch das Hilfmodul readingsProxy.
zu 3. Perfekt. Da habe ich auch keine weiteren Ideen. Seit gestern ist auch kein neues Gerät "aufgetaucht", kann durchaus sein, durch ein wackeliges hot-plug solche Fehler bei mir im Keller verursacht zu haben. Haken dran.
zu 4. Gerne, ich hatte wirklich versucht auf alle deine Fragen zu antworten. readingsProxy habe ich mir angeschaut, aber noch nicht ausprobiert. Kleiner Nachteil von diesem Weg: das muss man an jedem Dummy einzeln einrichten durch Anlage zweier Readings "readingsProxy" und "valueFn". Mein Notify hat die Anlage und Einrichtung eines neuen Dummys übernommen (ich weiß nice-to-have, aber hilfreich bei der Einrichtung des nächsten 10er Packs auch China)
zu 7. Diese Drei Fragezeichen sind der Default Wert für Dummy-Geräte, kommen nicht von mir.
Internals:
FUUID 6017279a-f33f-bea7-d881-9e67d1f133363804
NAME id019AD4380B000097
NR 95
STATE ???
TYPE dummy
Helper:
DBLOG:
id:
logdb:
TIME 1612180138.83781
VALUE dev4
READINGS:
2021-02-01 12:48:58 id dev4
Attributes:
event-on-change-reading .*
room OW2S0SLAVE
Für die Temperatursensoren hatte ich ein einfache Sichtbarkeit im State erreicht über:
stateFormat {"T: ".ReadingsNum($name,"temperature","")." (".int(ReadingsAge($name,"temperature",0.1)/60)." min alt)"}
Das vorhandene present/absent existiert ja "nur" für die DS2401. Aber das habe ich dankend übernommen, konkret in ein Reading "presence".
Was mir einfällt: zusätzliche "falsche" Devices sind
a) nicht kritisch, denn wir wollen aus Robustheitsgründen ja auf verschwindende Geräte triggern, also Kontakte mit NC an z.B. Fenstern verbauen.
b) man könnte vor dem Anlegen von Geräten einfach mehrere Bus-Abfragen abwarten. Also erst wenn z.B. Parameter 3 ... beim dritten Abfrage-Zyklus und in Folge die ID auf dem Bus liegt, wird sie wohl valide sein.
zu 8. Klar wird das schön! Bitte um Info, wenn ich helfen kann, sei es auch nur bei einer Übersetzung. Gesammelt hatte ich schon mal im wiki (da kann man gut Historie und Beispiele abbilden). Gab es schon Gelegeneheit den ersten Entwurf zu sichten? https://wiki.fhem.de/wiki/OW2S0SMSGUARD
9. (neu) Geräte seit gestern fehlerfrei. Mittags war mein mein Hausstrom weg (Zählerwechsel). Was es gibt sind vereinzelte Warnungen, die ich so vorher nicht sah (ich berichte morgen den Stand, mal schauen, ob zu den Uhrzeiten irgendwas besonderes war/ist):
2021.02.01 05:32:03 1: PERL WARNING: Illegal hexadecimal digit 'o' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 434.
2021.02.01 06:33:03 1: PERL WARNING: Illegal hexadecimal digit 'o' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 432.
2021.02.01 06:33:03 1: PERL WARNING: Illegal hexadecimal digit '�' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 432.
2021.02.01 06:33:03 1: PERL WARNING: Illegal hexadecimal digit 'o' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 442.
---- Zählerwechsel, also komplett Strom weg. Vorher hatte ich alles aus gemacht (fhem shutdown, sudo shutdown) ---
2021.02.01 12:52:47 1: PERL WARNING: Use of uninitialized value $data[1] in string eq at ./FHEM/00_OW2S0SMSGUARD.pm line 385.
2021.02.01 17:32:48 1: PERL WARNING: Illegal hexadecimal digit '�' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 432.
2021.02.01 17:32:48 1: PERL WARNING: Illegal hexadecimal digit '�' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 442.
2021.02.01 18:03:48 1: PERL WARNING: Illegal hexadecimal digit 'o' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 434.
2021.02.01 18:38:48 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/00_OW2S0SMSGUARD.pm line 542.
teste bitte mal diese Version, da sind einige Überprüfungen mehr drin.
U.a. findest du da auch ein neues Attribut use_subDevices :)
ACHTUNG : bitte FHEM neu starten , reload alleine wird vermutlich wieder schief gehen.
Guten Abend,
ich bin begeistert, dein Modul hat nun schon 833 Codezeilen. Fazit: absolut genial. Klappt alles, sogar eine Hilfe ist eingebaut, Sub-Devices via "Typ" verlinkt, so macht FHEM Spaß! Der Vollständigkeit halber, im Log (verbose 3) kam nur plausibles:
2021.02.03 00:28:57 3: usbmaster, got message for undefined device [01E5D9370B00005D] type DS2401 autocreate is enabled
2021.02.03 00:28:57 2: autocreate: define OW_01E5D9370B00005D OW2S0SMSGUARD 01E5D9370B00005D
2021.02.03 00:28:57 2: autocreate: define FileLog_OW_01E5D9370B00005D FileLog ./log/OW_01E5D9370B00005D-%Y.log OW_01E5D9370B00005D
2021.02.03 00:28:57 3: usbmaster, got message for undefined device [019AD4380B000097] type DS2401 autocreate is enabled
2021.02.03 00:28:57 2: autocreate: define OW_019AD4380B000097 OW2S0SMSGUARD 019AD4380B000097
2021.02.03 00:28:57 2: autocreate: define FileLog_OW_019AD4380B000097 FileLog ./log/OW_019AD4380B000097-%Y.log OW_019AD4380B000097
2021.02.03 00:28:58 3: usbmaster, got message for undefined device [2832AD4592100214] type DS18B20 autocreate is enabled
2021.02.03 00:28:58 2: autocreate: define OW_2832AD4592100214 OW2S0SMSGUARD 2832AD4592100214
2021.02.03 00:28:58 2: autocreate: define FileLog_OW_2832AD4592100214 FileLog ./log/OW_2832AD4592100214-%Y.log OW_2832AD4592100214
2021.02.03 00:28:58 3: usbmaster, got message for undefined device [28069D45921802D7] type DS18B20 autocreate is enabled
2021.02.03 00:28:58 2: autocreate: define OW_28069D45921802D7 OW2S0SMSGUARD 28069D45921802D7
2021.02.03 00:28:58 2: autocreate: define FileLog_OW_28069D45921802D7 FileLog ./log/OW_28069D45921802D7-%Y.log OW_28069D45921802D7
2021.02.03 00:28:59 3: usbmaster, got message for undefined device [2846794592180267] type DS18B20 autocreate is enabled
2021.02.03 00:28:59 2: autocreate: define OW_2846794592180267 OW2S0SMSGUARD 2846794592180267
2021.02.03 00:28:59 2: autocreate: define FileLog_OW_2846794592180267 FileLog ./log/OW_2846794592180267-%Y.log OW_2846794592180267
2021.02.03 00:28:59 3: usbmaster, got message for undefined device [2803DC4592150291] type DS18B20 autocreate is enabled
2021.02.03 00:28:59 2: autocreate: define OW_2803DC4592150291 OW2S0SMSGUARD 2803DC4592150291
2021.02.03 00:28:59 2: autocreate: define FileLog_OW_2803DC4592150291 FileLog ./log/OW_2803DC4592150291-%Y.log OW_2803DC4592150291
Was mir auffällt,
* Die Hilfeseite scheint nicht korrekt angezeigt (siehe Screenshot)?
* Die beiden Attribute "use_subDevices" und "map_OWIDs" sollten angepasst an die bestehenden vielleicht "useSubDevices" und "mapOWIDs" heißen, aber sicherlich sind die Unterstriche nicht kritisch (aber vielleicht stehen sie deshalb nicht korrekt im Hilfebereich)?
* Internal "OWDEVICES" für die Anzahl der Devices scheint entfallen?
* Kann man in den Sub-Devices ein Reading "presence" ausgeben? Dann wäre state "frei". (ich speichere reading "state" normalerweise nicht im dblog, readings "presence" und "temperature" hingegen schon).
* Kann man den Sub-Devices ein Attribut "alias" mit dem sprechenden Namen aus dem "map_OWIDs" verpassen, wenn vorhanden?
* dem DS2401-Sub-Device fehlt das Internal "busid"
Die Bus-ID (1, 2, 3...) bekomme ich leider im ReadingsProxy doch nicht in die Sub-Devices wenn man das Namensmapping nutzt (map_OWIDs), weil ich es nicht mehr zuordnen kann (OW-Dev0 2832AD4592100214 => 1). Wäre es noch ein großer Aufwand dieses bitte in die Sub-Devices zu schreiben (wie es für die DS18B20 schon geht)?
Aber das sind wirklich Kleinigkeiten, ich bin super super happy, wie toll das alles umgesetzt ist. Selbst an das Raum-Attribut hast du schon gedacht (room
OW2S0SMSGUARD), so dass man sofort Übersicht über alle Geräte hat, danke! Ich lasse mal wieder ein Tag laufen und berichte zur Stabilität...
Viele Grüße
ja bei der command.ref ist noch einiges zu tun , so ist das halt mit der leidigen Doku. Stichwort Doku : schau mal wieder in dein Wiki, pah hat dir da eine Anmerkung hinterlassen. Ich vermute du solltest da bis jetzt erfolgreich angebunden Typen ergänzen.
Aus Modulsicht sind es bis jetzt nur DS1820 , DS18B20 , DS1822 und der DS 2401
Attribute habe ich umbenannt, OWDEVICES dazu und presence auch.
Bus-ID , wenn es schön macht ... aber ich verstehe halt noch immer nicht warum du so wild auf die bist ?
Bei den DS2401 ändert sich die eh ständig je nachdem wer gerade am Bus ist und bei den Temp Sensoren hast auch Änderungen wenn einer dazukommt , wegfällt oder getauscht wird.
Alias :
Das ist genau so ein rotes Tuch für mich wie Dummys. Ich werde den Unsinn nicht direkt unterstützen, wer einen unbedingt haben will weil er zu faul ist das Device mittels rename umzubennen der soll ihn sich selbst anlegen !
Rooms :
da bin ich unschuldig, das macht autocreate von ganz alleine :) Aber als Modulautor kann man autocreate noch einige Optionen mit auf den Weg geben.
Danke für die wiederholt gute Nachricht! Wo hast du die aktuelle Version diesmal versteckt? Im Post#62 ist nichts, aber weiter vorne der Hinweis, dass es morgen via normalem Update kommt. Ok, dann teste ich morgen :D
ZitatBus-ID , wenn es schön macht ... aber ich verstehe halt noch immer nicht warum du so wild auf die bist ?
Anwendungsfall, man packt einen Sensor nach dem anderen an den Bus und kann auf die höchste Bus-ID schauen und weiß was in fhem zu konfigurieren ist. Hat sich durch deine Super-Auto-Sub-Device-Lösung deutlich entschärft.
ZitatBei den DS2401 ändert sich die eh ständig je nachdem wer gerade am Bus ist und bei den Temperatur-Sensoren hast auch Änderungen wenn einer dazukommt , wegfällt oder getauscht wird.
Anwendungsfall, wenn mehrere Temperatursensoren am Bus sind und sich ohne Konfigurationsänderungen "plötzlich" die Bus-id ändert, ist es ein Hinweis darauf, dass ein Teilnehmer zumindest zeitweise nicht verfügbar war.
Ist auf der Schnittstelle möglich die Firmware des USB-Masters auszulesen?
Die Wiki-Seite wächst, die funktionierenden Typen habe ich ergänzt und alles noch mal leserlich verbessert.
Grüße!
ja hatte ich gestern Abend vergessen zu schreiben , ab sofort täglich ab 8:00 Uhr
Mit den Bus-Ids fehlt mir mit meinen zwei Teilnehmern etwas die Erfahrung. Ich blicke da noch nicht durch wie die ihre Liste sortieren.
Kommen die Temp Sensoren immer alle vor den DS2401 ?
Mir ist kein Befehl bekannt , die Doku erwähnt hier ja nur $L+ , $? , $rez und $[0..63]
@Jostar, ich habe gerade eine Version hochgeladen mit einem set delay Kommando für den Master.
Da du einen Bus mit mehr DS18x Teilnehmer hast als ich kannst du da mal bitte diverse Werte testen 0 , 0.01 , 0.05 , usw ?
Hintergrund : laut SMS Doku kann man 1 Sekunde nach eintreffen der List Nachricht die einzel Werte abholen.
Leider machen sie aber keine Angabe wie groß die Wartzeit zwischen diesen Abfragen sein muß/darf , eventuell 0 ?
Bis jetzt hatte ich da 0.5 Sekunden fix, d.h. bei 30 Teilnehmer mit Werten am Bus würde es 15 Sekunden dauern bis alle abgeholt sind.
Ergebnis aus der Nacht:
2021.02.04 04:39:44 3: usbmaster, first byte �� <0 is not a number !
2021.02.04 04:55:37 1: PERL WARNING: Illegal hexadecimal digit '�' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 481.
2021.02.04 04:55:37 1: PERL WARNING: Illegal hexadecimal digit 'o' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 481.
2021.02.04 04:55:37 3: usbmaster, CRC error OW device 2 : 7F != b9
2021.02.04 05:14:37 1: PERL WARNING: Illegal hexadecimal digit '�' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 481.
2021.02.04 05:14:37 3: usbmaster, CRC error OW device 1 : 05 != e2
2021.02.04 05:15:37 3: usbmaster, first byte �<�2 is not a number !
Aktuellste Version (00_OW2S0SMSGUARD.pm:v2.0.0-s23667/2021-02-03) direkt nach Neustart:
2021.02.05 00:05:04 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/00_OW2S0SMSGUARD.pm line 633.
Eine merkwürdiges Reading wurde angelegt (sieht aus wie eine Sammlung von dreien). Zu der Uhrzeit gibt es keine weiteren Einträge im Log.
019AD4380B000097,019AD43892150291,01E5D9370B00005D absent 2021-02-05 00:08:54
Dabei sind das erste zwei Temperatursensoren, die dritte ID von einem DS2401, das gar nicht angeschlossen ist.
Neu sind Attribute "model", die stimmen aber nur für die DS18B20:
attr OW_2832AD4592100214 model DS18B20
Für das Gerät DS2401 mit DEF 019AD4380B000097:
attr OW_019AD4380B000097 model 019AD43892150291
internal hingegen korrekt "model DS2401"
get OWdevicelist bringt fhem zum Absturz (gerade geprüft, auch bei den älteren Versionen von diesem Jahr), der letzte Eintrag im log:
2021.02.05 00:14:03 1: PERL WARNING: Argument "_98_statistics" isn't numeric in int at ./FHEM/00_OW2S0SMSGUARD.pm line 307.
Can't use string ("Statistik_Strom") as a HASH ref while "strict refs" in use at ./FHEM/00_OW2S0SMSGUARD.pm line 308.
set delay kann ich weder im Set auswählen noch
"set delay 0.5" z.B. hat keinen erkennbaren Einfluss, bringt aber auch keine Fehlermeldung. "delay" kann ich nicht nach dem Feld "Set" auswählen (da sind nur "reset" und "s0reset"), wohl aber in die Befehlszeile direkt reinschreiben. Kommt wohl erst morgen früh übers Update, ok, dann mehr.
Rest scheint zu funktionieren.
Wieder ein ähnliches Verhalten am Morgen:
2021.02.05 00:54:29 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at FHEM/TimeSeries.pm line 269.
2021.02.05 07:20:28 1: PERL WARNING: Illegal hexadecimal digit '�' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 488.
2021.02.05 07:20:28 1: PERL WARNING: Illegal hexadecimal digit 'o' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 488.
2021.02.05 07:20:28 3: usbmaster, CRC error OW device 2 : 05 != 3c
2021.02.05 07:21:28 1: PERL WARNING: Illegal hexadecimal digit '�' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 488.
2021.02.05 07:21:28 3: usbmaster, CRC error OW device 2 : 7E != 67
2021.02.05 07:45:28 3: usbmaster, CRC error OW device 1 : 05 != 4b
2021.02.05 07:46:29 3: usbmaster, first byte �2 is not a number !
Für mich sieht das so aus, dass einzelne "Warnings" kommen, die nicht abgefangen sind, und andere sind abgefangen (Vergleich Zeitstempel).
wenn ich etwas einchecke und du das sofort haben möchtest musst du es direkt aus dem svn holen, das normale Update geht immer nur am nächsten Morgen nach 8:00 Uhr ! ( Thema set delay )
Man sieht du hast CRC Fehler und diese werden auch erkannt, die Perl Warnings kommen daher das es sich um Zeichen handelt die ausserhalb 0-F liegen, habe ich für die nächste Version gefixt. Bei der Gelegenheit habe habe ich auch gleich dein anderes Problem gelöst :
id2846794518180267 ???
id2846794592180267 T: 28.6 (0 min alt)
OWID = 8 Byte -> 1 Byte Family Kennung + 6 Byte Adresse + 1 Byte CRC
D.h. man brauch jetzt nur das CRC von Byte 1-7 selbst berechnen und mit Byte 8 vergleichen, dann fällt der 2846794518180267 sofort durchs Raster.
Warum bei dir get DevieList nicht geht ist mir schleierhaft, vor allem was da die 98_Statistics zu suchen hat.
Guten Abend,
DS18B20 alles gut (attr model DS18B20) und Internal addr 2803DC4592150291, busid 3, usbmaster_MSGCNT 170, und usbmaster_TIME 2021-02-06 00:38:26)
DS2401 leider verrutscht (model 019AD43892150291) (addr 019AD4380B000097, busid DS2401, usbmaster_MSGCNT 287, usbmaster_TIME 2021-02-06 00:45:34)
00_OW2S0SMSGUARD.pm:v2.0.0-s23674/2021-02-04 geht ein Tag in den Test.
Wie genau berechnet sich die Checksumme, nach welcher Vorschrift?
id2846794518180267 CRC: 28+46+79+45+18+18+02 = 236 ?= 67
id2846794592180267 CRC: 28+46+79+45+92+18+02 = 310 ?= 67
Grüße
Ahja, so wird die Checksumme berechnet, gefunden:
for my $i (2..10) { $crc += hex('0x'.$data[$i]); }
$crc = $crc & 0xFF;
if ($crc != hex('0x'.$data[11])) {
$txt = "CRC error OW device $num : ".$data[11]. ' != '. sprintf('%02x', $crc);
Log3($name, 3, "$name, $txt");
readingsSingleUpdate($hash, 'error', $txt, 1);
return;
}
Allerdings wird in der ersten Zeile (Nr. 499 im Code), nicht abgefangen, wenn es kein Hex ist. Gibt es vielleicht ein "looks_like_hex"? Aus der perl-docu finde ich: $valid_input =~ /\A(?:0?[xX])?(?:_?[0-9a-fA-F])*\z/, dass könnte man ja zumindest prüfen, oder?
In meinem Log der letzten Nacht:
2021.02.06 06:12:24 1: PERL WARNING: Illegal hexadecimal digit 'z' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 499.
2021.02.06 06:12:24 1: PERL WARNING: Illegal hexadecimal digit 'o' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 499.
2021.02.06 06:12:24 3: usbmaster, CRC error OW device 1 : 05 != 0c
2021.02.06 06:13:25 3: usbmaster, first byte 8<<2 is not a number !
Es läuft aber total stabil, keinerlei "Ausreißer" in den Temperaturwerten mehr, keine neuen Devices, die auf eine falsche ID hinweisen. Wirklich sehr gut!
Wie ist es sinnvoll das "delay" zu prüfen, doch eigentlich nur in Verbindung mit Interval oder sehr vielen Devices, oder?
Aktuell delay 0.1 und intervall 10 bei 6 Geräten. Mit delay (Standard 0.5) sollte ich bei gleichem Intervall 10 keinen Unterschied entdecken, oder?
Du darfst bei der CRC Prüfung nicht Äpfel mit Birnen vergleichen. Das was SMS-GUARD da als zusätzliches Byte anbietet dient ja nur der Überprüfung der gelesenen & übertragenen Werte. Das achte Byte in der OW Id ist ne ganz andere Nurmmer und wird auch etwas komplexer errechnet als das andere, gibt aber im Netz genug Beispiele dazu bzw. man kann auch in den anderen OWX Modulen auf Beutezug gehen.
Das die zwei Zeichen als gültiges HEX geprüft werde müssen hatte ich ja bereits geschrieben und auch umgesetzt, allerdings geht die RegEx auch wesentlich einfacher als deine Variante : m{ [0-9A-F]+ }x sollte alles erschlagen (Kleinbuchstaben a-f kommen nicht vor )
Thema Intervall : Keine Ahnung ob es auch mit 0 oder 0.01 ohne Fehler läuft, das sollst du ja mal testen da ich zuwenig Chips habe.
Ich habe eben eine neue Version hochgeladen, bitte bei Gelegenheit prüfen und melden was nun aktuell mit dieser Version noch an Problem anliegt.
Das Thema Meldung beim FHEM Start sollte erledigt sein, ebnso die Warnings beim CRC Check.
Der Tausch von model und busid kann ich mir nicht erklären genau wie das Thema mit OWdevicelist.
Da hier etwas von _98_statistics und Statistik_Strom steht was hast du denn da angelegt ?
Danke, alles klar soweit. Neue Version schaffe ich erst morgen anzuschauen. Weil du fragtest:
Statistik_Strom (TYPE statistics) mit
singularReadings usbmaster:total:Delta:Hour|usbmaster:total:Delta:Day|usbmaster:total:Delta:Month|usbmaster:total:Delta:Year
berechnet ein paar Stände von "total", was bei mir im "usbmaster" ein akkumulierter Zählerstand ist (der den Zählerstand "A" im OW2S0SMSGUARD in Kubikmeter Gas umrechnet). Er wird gebildet im usbmaster mit:
userReadings total:A { ReadingsNum($NAME,"Abase",0)+ReadingsNum($NAME,"A",1)/100 }
Abase ist ein absoluter Wert vom Gaszähler (nach S0-reset zum Beispiel anzupassen, oder wenn es Abweichung beim "mitzählen" des Reed-Kontaktes am Gaszähler gibt).
if ($cmd eq 'OWdevicelist') {
my @devs;
foreach my $dev ( sort keys %{$hash->{helper}} ) {
next if (int($dev) == 100);
die untere Zeile ist der Auslöser. Ich habe die Geräte gelöscht, sie wurden neu angelegt, einfach klasse. Aber das Problem bleibt leider. Kann es eine Querverbindung der "alten" OW2S0SLAVE Geräte geben? Die habe weiter betrieben (um mit setreading "befüllt").
Ist Statistik_Strom deaktiviert (Attr disable 1), bleibt der Fehler, lösche ich das Gerät (delete), kann man gefahrlos OWdevicelist ausführen.
Wie gesagt, morgen teste ich aktuellste Version, dann kommt mehr Input.
OK THX , dann ist alles klar :)
Sowohl Statistics als auch z.B. DbLog erzeugen eigene Einträge unterhalb $hash->{helper}
00_OW2S0SMSGUARD.pm:v2.0.0-s23686/2021-02-06
startet "unauffällig", eine Warnung ist noch drin:
2021.02.07 10:35:32 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/00_OW2S0SMSGUARD.pm line 692.
zwei Geräte DS2401 manuell gelöscht, wurden angelegt:
2021.02.07 10:42:53 3: usbmaster, got message for undefined device [01E5D9370B00005D] type DS2401 autocreate is enabled
2021.02.07 10:42:53 2: autocreate: define OW_01E5D9370B00005D OW2S0SMSGUARD 01E5D9370B00005D 0 DS2401
2021.02.07 10:42:53 2: autocreate: define FileLog_OW_01E5D9370B00005D FileLog ./log/OW_01E5D9370B00005D-%Y.log OW_01E5D9370B00005D
2021.02.07 10:43:03 3: usbmaster, got message for undefined device [019AD4380B000097] type DS2401 autocreate is enabled
2021.02.07 10:43:03 2: autocreate: define OW_019AD4380B000097 OW2S0SMSGUARD 019AD4380B000097 0 DS2401
2021.02.07 10:43:03 2: autocreate: define FileLog_OW_019AD4380B000097 FileLog ./log/OW_019AD4380B000097-%Y.log OW_019AD4380B000097
Auch die Internals sehen gut aus und reagieren bei einem Gerät abschließen/anschließen erwartungsgemäß:
OW-Dev0 2832AD4592100214 => 1
OW-Dev1 28069D45921802D7 => 1
OW-Dev2 2846794592180267 => 1
OW-Dev3 2803DC4592150291 => 1
OW-Dev4 019AD4380B000097 => 1
OWDEVICES 5
Der "erste" DS2401 wird noch korrekt angelegt:
Internals:
CFGFN
DEF 01E5D9370B00005D 0 DS2401
DELAY 0.5
FUUID 601fb771-f33f-bea7-175e-3afb3879239afa0d
FVERSION 00_OW2S0SMSGUARD.pm:v2.0.0-s23686/2021-02-06
LASTInputDev usbmaster
MSGCNT 45
NAME OW_01E5D9370B00005D
NOTIFYDEV global
NR 193
NTFY_ORDER 50-OW_01E5D9370B00005D
STATE absent
SVN 23686
TYPE OW2S0SMSGUARD
addr 01E5D9370B00005D
busid -1
usbmaster_MSGCNT 45
usbmaster_TIME 2021-02-07 10:56:04
Helper:
DBLOG:
presence:
logdb:
TIME 1612691323.87866
VALUE absent
READINGS:
2021-02-07 10:56:04 presence absent
2021-02-07 10:56:04 state absent
Attributes:
event-on-change-reading .*
model DS2401
room OW2S0SMSGUARD
das zweite passt leider nicht (busid):
Internals:
CFGFN
DEF 019AD4380B000097 0 DS2401
DELAY 0.5
FUUID 601fb799-f33f-bea7-a1a4-6d6279ef792a48b4
FVERSION 00_OW2S0SMSGUARD.pm:v2.0.0-s23686/2021-02-06
LASTInputDev usbmaster
MSGCNT 95
NAME OW_019AD4380B000097
NOTIFYDEV global
NR 212
NTFY_ORDER 50-OW_019AD4380B000097
STATE present
SVN 23686
TYPE OW2S0SMSGUARD
addr 019AD4380B000097
busid DS2401
usbmaster_MSGCNT 95
usbmaster_TIME 2021-02-07 10:57:04
Helper:
DBLOG:
presence:
logdb:
TIME 1612691363.85473
VALUE present
READINGS:
2021-02-07 10:57:04 presence present
2021-02-07 10:57:04 state present
Attributes:
event-on-change-reading .*
model DS2401
room OW2S0SMSGUARD
DELAY 0.1 steht im OW2S0SMSGUARD Master "usbmaster", die beiden Geräte zeigen im Internal aber 0.5 für delay.
Zitat von: Jostar am 07 Februar 2021, 10:59:20
eine Warnung ist noch drin
-- snipp --
das zweite passt leider nicht (busid):
-- snipp --
DELAY 0.1 steht im OW2S0SMSGUARD Master "usbmaster", die beiden Geräte zeigen im Internal aber 0.5 für delay.
1. ist in der nächsten Version gefixt
2. ahh ok, dann muss ich mal einen zweiten simulieren
3. delay hat bei Slaves keine Bedeutung, daher die 0.5 als default , werfe ich noch raus
Mal schauen ob ich bis heute Abend ne neue Version hinbekomme, ansonsten morgen.
gefixte Version ist ab morgen 8:00 Uhr verfügbar
Im Test nun 4xTemperatur, 2 x DS2401 und 2 x DS2401 (offline, also nach der Erkennung wieder vom Bus getrennt):
OW-Dev0 2832AD4592100214 => 1
OW-Dev1 28069D45921802D7 => 1
OW-Dev2 2846794592180267 => 1
OW-Dev3 2803DC4592150291 => 1
OW-Dev4 019AD4380B000097 => 1
OW-Dev5 0196553A0B0000EB => 1
Der Bericht aus der Nacht, einige Auffälligkeiten wurden sauber erkannt:
2021.02.08 04:12:02 3: usbmaster, message is too short -> 1
2021.02.08 08:25:12 3: usbmaster, first byte <<<�0 is not a number !
2021.02.08 08:27:12 3: usbmaster, first byte �<<�0 is not a number !
2021.02.08 08:29:12 3: usbmaster, first byte x�<<�0 is not a number !
2021.02.08 08:32:03 3: usbmaster, first byte ��<<<�3 is not a number !
2021.02.08 08:33:03 3: usbmaster, CRC error OW device 2 : 126 != 170
2021.02.08 08:37:03 3: usbmaster, CRC error OW device 1 : 127 != 141
2021.02.08 08:40:04 3: usbmaster, CRC error OW device 0 : 127 != 116
2021.02.08 11:04:09 3: usbmaster, CRC error OW device 5 : 102 != 195
00_OW2S0SMSGUARD.pm:v2.0.0-s23693/2021-02-07 angekommen. Der auffällig Sensor ist leider noch immer da. Ich hatte auch schon Reset probiert, sehr komisch. Im Logfile nun alle 10 Sekunden Hinweise:
2021.02.08 12:02:42 3: usbmaster: Unknown code OW,01E5D9370B00005D 01E5D9370B00005D,DS2401,absent,-1, help me!
2021.02.08 12:02:42 3: usbmaster: Unknown code OW,013AEC370B0000EB 0196553A0B0000EB 019AD4380B000097 019AD4380B000097,DS2401,absent,-1, help me!
2021.02.08 12:02:52 3: usbmaster: Unknown code OW,01E5D9370B00005D 01E5D9370B00005D,DS2401,absent,-1, help me!
2021.02.08 12:02:52 3: usbmaster: Unknown code OW,013AEC370B0000EB 0196553A0B0000EB 019AD4380B000097 019AD4380B000097,DS2401,absent,-1, help me!
Es ist in der Logdatei zum Device ebenfalls (nicht in meiner Datenbank, da es dort zu einem Zeitstempel nur einen Eintrag pro Gerät und Reading geben kann):
2021-02-08_11:53:40 OW_019AD4380B000097 busid: DS2401
2021-02-08_11:53:40 OW_019AD4380B000097 busid: 4
2021-02-08_11:53:50 OW_019AD4380B000097 busid: DS2401
2021-02-08_11:53:50 OW_019AD4380B000097 busid: 4
2021-02-08_11:54:00 OW_019AD4380B000097 busid: DS2401
2021-02-08_11:54:00 OW_019AD4380B000097 busid: 4
2021-02-08_11:55:00 OW_019AD4380B000097 busid: DS2401
2021-02-08_11:55:00 OW_019AD4380B000097 busid: 4
2021-02-08_11:55:10 OW_019AD4380B000097 busid: DS2401
2021-02-08_11:55:10 OW_019AD4380B000097 busid: 4
2021-02-08_11:55:20 OW_019AD4380B000097 busid: DS2401
2021-02-08_11:55:20 OW_019AD4380B000097 busid: 4
Neue Sub-Devices bekommen automatisch die folgenden Attribute (sehr gute Entscheidung):
event-on-change-reading .*
timestamp-on-change-reading .*
sehr schön, das mit dem Unknown code ist in sofern richtig da das eigentliche Telegramm fehlerhaft ist und wird quasi abgewiesen bevor da irgendwelcher Müll in die Readings kommt.
Zu deinen Sorgenkindern habe ich noch eine Idee : du solltest dir mal mit list das versteckte Reading .ds2401 anschauen, ich vermute da steht bei dir Müll drin. Daher am einfachsten mal löschen, bzw ich würde dir eh raten für diese ganze Testerei unter global showInternalValues auf 1 zu setzen damit du alle verteckten Internals und Readings sofort in FHEMWEB siehst.
Wenn das .ds2401 dann sauber ist und die aktuellen DS2401 erkannt werden kannst später immer mit dem neuen set Kommando deleteDS2401 Ordnung schaffen falls mal einer komplett aus deinem System raus soll.
Was genau soll ich löschen? Das Reading habe ich versucht, bringt nichts. Der "Blödsinn" nimmt eher zu:
Readings im OW2S0SMSGUARD "master" (usbmaster)
.ds2401
013AEC370B0000EB,013AEC370B0000EB 0196553A0B0000EB 019AD4380B000097 019AD4380B000097,0196553A0B0000EB,019AD4380B000097,019AD43892150291,01E5D9370B00005D,01E5D9370B00005D 01E5D9370B00005D 2021-02-08 13:39:33
013AEC370B0000EB absent 2021-02-08 13:39:33
013AEC370B0000EB 0196553A0B0000EB 019AD4380B000097 019AD4380B000097 absent 2021-02-08 13:39:33
0196553A0B0000EB present 2021-02-08 13:39:33
019AD4380B000097 present 2021-02-05 00:29:42
019AD4380B000097,019AD43892150291,01E5D9370B00005D absent 2021-02-08 11:56:00
019AD43892150291 absent 2021-02-08 13:39:33
01E5D9370B00005D absent 2021-01-31 15:52:59
01E5D9370B00005D 01E5D9370B00005D absent 2021-02-08 13:39:33
Set deleteDS2401 zeigt aktuell nur zwei Einträge, zwei mal "013AEC370B0000EB" im Auswahlfeld.
deletereading usbmaster .ds2401
oder mal komplett aufräumen
deletereading usbmaster .*
man sieht ja
013AEC370B0000EB,013AEC370B0000EB 0196553A0B0000EB 019AD4380B000097 019AD4380B000097,0196553A0B0000EB,019AD4380B000097,019AD43892150291,01E5D9370B00005D,01E5D9370B00005D
das sollte eine Kommata getrennte Liste sein, bei dir befinden sich allerdings teilweise auch Leerzeichen zwischen den Adressen und das geht halt leider schief.
Ich habe eine neue Version hochgeladen.
a. Beim Abziehen des Adapters und wieder anstecken dauerte es gefühlt ewig bis der USB disconneted Status aufgehoben wurde. Trat auch beim S0-Reset auf
Aufgefallen ist es als ich ihn via ser2net angebunden hatte
b. Da ich noch einen DS1820 bekommen habe konnte ich jetzt selbst das Thema delays testen. Das Set Kommando ist jetzt in die Attribute gewandert so das der Wert nun auch nach einem FHEM Neustart direkt wieder aktuell ist.
Sehr gut. Die folgenden Luxusprobleme hatte mich nicht getraut anzusprechen...
* Set vs Attr für "delay" (funktioniert ja, Lösung im attr für restart-fest ist natürlich besser)
* langes reconnect (USB-Stecker trennen) hatte ich durch restart fhem abgekürzt (passiert ja eigentlich nie)
* saubere Sub-Devices habe ich geschafft zu bekommen, allerdings wirklich durch löschen und Neuanlage des Gerätes OW2S0SMSGUARD (der Historie geschuldet)
Insgesamt läuft es ziemlich stabil, wirklich sehr gut. Die Temperaturverläufe sehe nun aus wie "geleckt", keinerlei Aussetzer oder ähnliches. Auswirkung delay kann ich nicht erkennen. Ich habe alle paar Stunden mal ein Problemchen in den Checks, auffällig, früh gegen 7 Uhr täglich (Heizung läuft ab 5 Uhr, keine Ahnung, woran das liegen könnte).
Ein Check wird erst in der Checksumme abgefangen, führt vorher aber zu 5 Warnungen (4 Temp-Sensoren + 2 DS2401 am Bus). Wäre wohl besser vorher abzufangen:
Zeilennummer 524 bzw. 529 bezieht sich auf 00_OW2S0SMSGUARD.pm:v2.0.0-s23693/2021-02-07:
2021.02.09 14:33:08 3: usbmaster, first byte �<<<�1 is not a number !
2021.02.09 15:09:09 1: PERL WARNING: Illegal hexadecimal digit '�' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 524.
2021.02.09 15:09:09 1: PERL WARNING: Illegal hexadecimal digit '�' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 524.
2021.02.09 15:09:09 1: PERL WARNING: Illegal hexadecimal digit '�' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 524.
2021.02.09 15:09:09 1: PERL WARNING: Illegal hexadecimal digit '�' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 524.
2021.02.09 15:09:09 1: PERL WARNING: Illegal hexadecimal digit '�' ignored at ./FHEM/00_OW2S0SMSGUARD.pm line 529.
2021.02.09 15:09:09 3: usbmaster, CRC error OW device 4 [019AD4� �������0] : �0 != 02
2021.02.09 15:10:08 3: [notify_usbmaster] Device OW_019AD4380B000097 wurde behandelt (busid: -1)
2021.02.09 15:10:18 3: [notify_usbmaster] Device OW_019AD4380B000097 wurde behandelt (busid: 4)
2021.02.09 15:11:08 3: usbmaster, message is too short -> 1
2021.02.09 15:12:08 3: usbmaster, message is too short -> 1
2021.02.09 20:53:10 3: usbmaster, CRC error OW device 2 : 127 != 124
2021.02.09 20:57:10 3: usbmaster, CRC error OW device 1 : 127 != 144
2021.02.09 21:00:10 3: usbmaster, first byte =<<<�1 is not a number !
2021.02.09 21:23:11 3: usbmaster, CRC error OW device 5 : 102 != 205
2021.02.09 21:24:10 3: usbmaster, message is too short -> 2
Ein mal am Tag ist ein Gerät "verschwunden" (OW_019AD4380B000097). Mein notify auf ein Reading "busid" hat den Logbucheintrag (oben unter [notify_usbmaster]) erzeugt.
Wenn man ein "Alarm" für DS2401 nutzt (bei Verschwinden), sollte man eben zwei, drei Intervalle abwarten für mehr Sicherheit. Der Fall "Hinzukommen" für Alarmtrigger scheint mir Fehlalarm gänzlich ausschließen, hat aber zwei Nachteile (siehe auch ältere Antworten):
* für einen sehr kurzen Moment nach dem Hinzukommen, ist der Master für andere Nachrichten "blind"
* Kabeldefekt, Sabotage etc. kann nicht automatisch überwacht werden (es sei denn, am Busende wacht ein DS2401 darüber)
Sowohl für "Erscheinen", als auch "Verschwinden" habe ich es geschafft, dass andere Geräte eine neue busid bekommen.
OWdevicelist scheint ein Gerät zu fehlen (das Popup zeigt nur 7):
# | Type | Address | Name | Time
--+---------+------------------+------------------------+--------------------
0 | DS18B20 | 2832AD4592100214 | Stubenfussbodenlinksp | 2021-02-09 22:40:22
1 | DS18B20 | 28069D45921802D7 | Stubenfussbodenrechtsp | 2021-02-09 22:40:22
2 | DS18B20 | 2846794592180267 | Stubenfussbodenrechts | 2021-02-09 22:40:22
3 | DS18B20 | 2803DC4592150291 | Stubenfussbodenlinks | 2021-02-09 22:40:22
4 | DS2401 | 019AD4380B000097 | Rauchstatus | 2021-02-09 22:40:22
5 | DS2401 | 0196553A0B0000EB | 0196553A0B0000EB | 2021-02-09 22:40:22
6 | DS2401 | 0196553A0B0000EB | 0196553A0B0000EB | 2021-02-09 22:19:22
Angelegt sind 8, siehe Readings:
2021-02-09 22:43:23 .ds2401 013AEC370B0000EB,0196553A0B0000EB,019AD4380B000097,01E5D9370B00005D
2021-02-09 00:17:04 013AEC370B0000EB unkown
2021-02-09 00:17:04 0196553A0B0000EB unkown
2021-02-08 14:06:59 019AD4380B000097 present
2021-02-08 14:06:59 01E5D9370B00005D present
2021-02-08 14:07:01 2803DC4592150291 28.9
2021-02-08 14:07:00 28069D45921802D7 29.3
2021-02-08 14:07:00 2832AD4592100214 30.2
2021-02-08 14:07:01 2846794592180267 31.2
Der Doku für das Get fehlt der Befehl "OWdevicelist"
Get
list of found OW devices ( master only )
Wie ist denn der Aufbau via ser2net, welcher Adpater eignet sich? Mir scheint der Nutzen via Adapter den USB-Port auf Ethernet zu bringen hoch, am besten noch mit Stromversorgung, also PoE.
Zitat von: Jostar am 09 Februar 2021, 22:52:58
Ein Check wird erst in der Checksumme abgefangen, führt vorher aber zu 5 Warnungen (4 Temp-Sensoren + 2 DS2401 am Bus). Wäre wohl besser vorher abzufangen:
Die Warnungen kommen aus decodeList und deren Aufruf hängt an :
return decodeList($hash, $name, $num, $ok, @data) if (defined($data[2]) && (length($data[2]) == 16) && ( $data[2] =~ m{ [0-9A-F]+ }x ));D.h. solche zerstörten OW Adressen /data[2] sollten eigentlich erst gar nicht durch m{ [0-9A-F]+ }x kommen :(
Da gehen mir nun langsam die Ideen aus. Edit :
arggg ich Depp, statt + sollte {16} die Lösung sein und die Längenprüfung erschlägt es auch gleich mit
Zitat
Ein mal am Tag ist ein Gerät "verschwunden" (OW_019AD4380B000097). Mein notify auf ein Reading "busid" hat den Logbucheintrag (oben unter [notify_usbmaster]) erzeugt.
warum auf busid ? Das Subdevice hat doch absent/present ? Das sollte eigentlich zuverlässig sein.
Zitat
OWdevicelist scheint ein Gerät zu fehlen (das Popup zeigt nur 7):
Zeig mir mal ein list von deinem usbmaster. Und Vorsicht : es wird nicht gelistet was jemals gesehen wurde (.ds2401) sondern nur was aktuell nach dem letzten Neustart gesehen wurde.
Zitat
5 | DS2401 | 0196553A0B0000EB | 0196553A0B0000EB | 2021-02-09 22:40:22
6 | DS2401 | 0196553A0B0000EB | 0196553A0B0000EB | 2021-02-09 22:19:22[/code]
copy & paste Fehler oder steht der wirklich doppelt in der Liste ?
Zitat
Wie ist denn der Aufbau via ser2net, welcher Adpater eignet sich?
Ich habe einfach den USB Port an meinem Testsystem via ser2net im Netz freigegeben und an einem anderen PC mir den usbmaster geholt mit
define <name> OW2S0USBMASTER IP:Port Echte Seriell/TCP Adapter besitze ich keinen, daher kann ich auch keine Empfehlung abgeben.
die HEX Prüfung hat nun jetz eine eigene sub bekommen um die 1 und 8 Byte Varianten zusammen erschlagen zu können, d.h. morgen ab 8:00 Uhr :
neues Spiel, neues Glück
Kurz die Antworten:
ja, copy&paste kam vom OWdevicelist, da kann mir kein Fehler passiert sein. Heute sieht es wieder aus wie erwartet, aber gestern war es wie berichtet.
Zitatwarum auf busid ? Das Subdevice hat doch absent/present ? Das sollte eigentlich zuverlässig sein.
Ja, ginge auch, aber dann bekomme ich nicht mit, wenn sich nur die Durchnummerierung ändert. Die Art der Durchnummerierung ist wie würfeln, nehme ich einen Teilnehmer weg oder einen hinzu, kann es sein, dass die busid eines anderen sich ebenfalls ändert, aber reading presence gleich bleibt.
Falls sich wer für ein auto-rename der Sub-Devices interessiert, so ist meine Lösung über ein notify das Attribut "mapOWIDs" vom OW2S0SMSGUARD (Master) auszuwerten:
.*:(busid):.* {
if ($EVENT) {
Log3 $NAME, 5, "[$SELF] Device $NAME wurde behandelt ($EVENT)";
}
my @owdevs = split(/,\s?/, AttrVal("usbmaster","mapOWIDs",""));
my @owname;
foreach my $owdev (@owdevs) {
@owname = split(/\=/,$owdev);
if (exists($defs{"OW_".$owname[0]})) {
fhem("rename OW_".$owname[0]." ".$owname[1]);
Log3 $NAME, 3, "[$SELF] Device ".$owname[0]." in ".$owname[1]." umbenannt";
}
}
Log3 $NAME, 4, "[$SELF] Devices ".join("-",@owdevs);
}Auffälligkeiten ()
2021.02.10 18:21:17 3: usbmaster, first byte ��|��������|jR"�4 is not a number !
2021.02.10 18:21:17 3: [notify_usbmaster] Device Testlinks wurde behandelt (busid: -1)
2021.02.10 18:21:27 3: [notify_usbmaster] Device Testlinks wurde behandelt (busid: 4)Wenn wir in dem Intervall einen Fehler haben in der Antwort (Zeile 1), wie kann es dann sein, dass wir das Telegram trotzdem auswerten und "Testlinks" verlieren?
Hinweis: Zu den passenden Zeitstempeln wird das reading presence am Gerät "Testlinks" passend auf absent und dann wieder auf present registriert.
Aus meiner Sicht sollte in dem Intervall dann kein Update erfolgen.
Grüße!
Zitat von: Jostar am 11 Februar 2021, 00:09:41
Ja, ginge auch, aber dann bekomme ich nicht mit, wenn sich nur die Durchnummerierung ändert. Die Art der Durchnummerierung ist wie würfeln, nehme ich einen Teilnehmer weg oder einen hinzu, kann es sein, dass die busid eines anderen sich ebenfalls ändert, aber reading presence gleich bleibt.
Wieso wie würfeln ? Das Ding hat kein Gedächnis, jedes $? löst einen Scan des 1W Bus aus und dann wird gelistet was gerade aktuell gefunden wurde.
Wenn ein Teilnehmer (warum auch immer) fehlt rücken die nachfolgenden auf. D.h. ab diesem ändern sich die aktuellen busids. Bei Temeperatur Sensoren könnte man das noch überwachen, denn die sollten ja immer da sein, aber bei den DS2401 ist doch völlig unklar ob er sich wegen einer Störung nicht gemeldet hat oder er eben gewollt fehlt.
Ähnlich verhält sich die Auswertung im Modul. Die Antwort des USB Masters kommt nicht am Stück sondern in kleinen Teilen bei der sub read an (siehe verbose 5 Log) und wird ausgewertet (sub Parse) sobald ein Zeilenumbruch erkannt wurde. Ist in der Zeile ein Fehler (not an number) oder enthält zuwenig Elemente wird sie verworfen, die nächste kann aber durchaus wieder ok sein und wird dann auch entsprechend verarbeitet. Betraf die verworfene Zeile einen DS2401 "fehlt" dieser natürlich am Schluss und wird auf absent gesetzt. D.h. das Modul hat keine Ahnung ob er jetzt wegen eines Fehlers absent ist oder er sich wirklich nicht gemeldet hat.
Deine Idee den ganzen Rest zu verwerfen würde bedeuten das z.b. das list Telegramm erst komplett gesammelt wird (bis zu den beiden S0) und erst danach zur Auswertung an Parse weitergeleitet wird.
Schauen wir doch mal für was die Hardware gebaut wurde : 2 x S0 -> prima, nur ein paar Temp Sensoren -> auch gut , beides zusammen -> geht auch, aber DS2401 kommen in deren Konzept nicht vor, genau so wenig wie andere mögliche 1W Teilnehmer. Sinnvoll wäre auch aus Modulsicht wenn mit DS2401 gearbeitet wird diese exklusiv an einem Gerät & Bus zu beteiben und das dem Modul klar mizuteilen, dann kann man einfach Extrawürste braten. Setzt man dagegen wie heute auf Mischbetrieb dann muss man mit diesen Einschränkungen leben. Sowohl die FHEM Stats als auch die User Beiträge hier im Thread legen die Vermutung nah das du da wohl ziemlich alleine bist.
Edit : die heutige Version hat leider einen kleinen Fehler in Zeile 668 -> validHex statt IsValidHex
dadurch wird das Modul nicht geladen, Update morgen
Danke für die Erklärungen, ich hatte angenommen (aufgrund des gleichen Zeitstempels), dass die Information zum DS2401 "Testlinks" in der ersten Zeile stehen:
2021.02.10 18:21:17 3: usbmaster, first byte ��|��������|jR"�4 is not a number !
2021.02.10 18:21:17 3: [notify_usbmaster] Device Testlinks wurde behandelt (busid: -1)
2021.02.10 18:21:27 3: [notify_usbmaster] Device Testlinks wurde behandelt (busid: 4)
Wenn ich die Ausführung richtig verstanden habe, muss das aber nicht stimmen. Ok. Dann spricht ja nichts dagegen zeilenweise die Telegramm auf formelle Korrektheit einzeln zu prüfen. Nur das Verhalten, das könnte man noch überdenken:
* Aus meiner Sicht sollte eine Zeile, die formell nicht in Ordnung ist, keinen Einfluss auf das Setzen von Readings haben. Ja, das Modul "weiß" nicht, ob das DS2401 in dem Fall noch vorhanden ist, aber es "weiß", dass in der Telegrammzeile etwas nicht stimmt. Von daher wäre die Reaktion so wie beim einer Checksummenprüfung: Zeile verwerfen, Fehlerlogeintrag.
* Sichtbar wäre in dem Fall eine ausbleibende Aktualisierung im Zeitstempel (Will doch wer einen Trigger generieren, wenn länger als Intervall-Zeit kein Update kam, könnte man das leicht überwachen mit DOIF oder watchdog)
Optional vielleicht ein Verhalten analog wie ein Presence mit LAN-Ping arbeitet:
* present (wenn Nachricht ankommt)
* maybe (wenn irgendwas in der Telegramzeile "kaputt" ankommt)
* absent (wenn ID nicht gefunden wird)
Aber aus meiner Sicht sind hier keine Aktionen nötig. Das "stabilere" Verhalten lässt sich einfach erreichen, was z.B. auf ein "absent" über 3 Intervalls triggert.
Mit dem Hersteller habe ich telefoniert. Er meinte, die Nachfrage ist stark zurück gegangen über die letzten Jahre, der Adapter wird nicht mehr produziert, nur noch sehr geringe Bestände im Lager. Es gibt wohl auch im Shop Alternativprodukte zu ähnlichem Preis, habe ich mir aber noch nicht angeschaut. In der Variante "ISO" (galvanischer Trennung zum Bus, etwas länger und teurer) ist das Lager aber noch gut gefüllt.
Zitat von: Jostar am 11 Februar 2021, 21:56:51
eine Zeile, die formell nicht in Ordnung ist, keinen Einfluss auf das Setzen von Readings haben.
-- snipp --
könnte man das leicht überwachen mit DOIF oder watchdog)
-- snipp --
* maybe (wenn irgendwas in der Telegramzeile "kaputt" ankommt)
-- snipp ---
auf ein "absent" über 3 Intervalls triggert.
a. nun bei Temp Sensoren ist es zu 100% so, bei den DS2401 ist halt nicht bekannt wenn es hier via error ewischt hat.
b. oder (Achtung Eigenwerung) : readingsWatcher :)
c. das wäre eine Variante da ja der Zeitstempel der letzten present Meldung bekannt ist. Erfordert wieder ein Attribut da der User diese Zeitspanne festlegen muss - entweder als Multiplikator zum Intervall oder direkt in Sekunden.
d. dann darf der Intervall aber nicht zu groß sein - das wäre wie c. mit Faktor
ich schau mal das mit present + Timeout -> maybe + Timeout -> absent scheint eigentlich relativ einfach zu sein.
habe gerade eine neue Version hochgeladen : neues Attribut DS2401_Timeout -> default 1,5 x intervall
Das Attribut darf nicht kleiner als intervall gesetzt werden -> Fehlermeldung
Gleich intervall ist zwar zulässig, aber ich rate davon ab, denn es besteht dann die Gefahr das intern beim runden der Millisekunden auf Sekunden man ein timeout/absent erhält das nicht stimmt.
Mit allen Werten etwas größer als Intervall ist man immer auf der sicheren Seite ( daher default 1,5 x intervall )
Funktion : Wird ein DS2401 der im letzten Zyklus noch present war im aktuellen nicht gesehen ändert sich sein Status auf "timeout".
Ist er bei der nächsten Runde wieder dabei geht er zurück auf present , fehlt er dagegen wieder wechselt er auf absent.
Das stimmt so bei einem Timeoutwert kleiner ist als die doppelten Intervall Zeit, ausdehen kann man es aber beliebig durch größere Timeout Werte.
@Jostar, du könntest mir mal eine Gefallen tun und einen Durchlauf mit verbose 5 loggen.
Ich hätte gern mal die Hex Werte deiner Temperaturen da du wohl 18B20 oder 1822 im Einsatz hast, ich habe leider nur die 18S20 mit Family Code 01.
Gerne, für
00_OW2S0SMSGUARD.pm:v2.0.0-s23734/2021-02-13
anbei ca. 1 Minute, inkl. restart und ohne aktive Änderungen am Bus (also kein Teilnehmer kommt oder geht):
# | Type | Address | Name | Time
--+---------+------------------+------------------------+--------------------
0 | DS18B20 | 2832AD4592100214 | Stubenfussbodenlinksp | 2021-02-14 09:44:25
1 | DS18B20 | 28069D45921802D7 | Stubenfussbodenrechtsp | 2021-02-14 09:44:25
2 | DS18B20 | 2846794592180267 | Stubenfussbodenrechts | 2021-02-14 09:44:25
3 | DS18B20 | 2803DC4592150291 | Stubenfussbodenlinks | 2021-02-14 09:44:25
4 | DS2401 | 019AD4380B000097 | Testlinks | 2021-02-14 09:44:25
5 | DS2401 | 0196553A0B0000EB | Rauchalarm | 2021-02-14 09:44:252021.02.14 09:40:01 1: usb create starting
2021.02.14 09:40:02 3: Probing ZWDongle device /dev/serial1
2021.02.14 09:40:02 3: Probing CUL device /dev/ttyAMA0
2021.02.14 09:40:02 3: Probing TCM_ESP3 device /dev/ttyAMA0
2021.02.14 09:40:02 3: Probing ZWDongle device /dev/ttyAMA0
2021.02.14 09:40:02 3: Probing SIGNALDuino device /dev/ttyAMA0
2021.02.14 09:40:03 3: Probing MYSENSORS device /dev/ttyAMA0
2021.02.14 09:40:03 3: Probing ArduCounter device /dev/ttyAMA0
2021.02.14 09:40:03 3: Probing ElsnerWS device /dev/ttyAMA0
2021.02.14 09:40:04 3: Probing FRM device /dev/ttyAMA0
2021.02.14 09:40:09 1: usb create end
2021.02.14 09:40:09 5: usbmaster, restore hash for 013AEC370B0000EB
2021.02.14 09:40:09 5: usbmaster, restore hash for 0196553A0B0000EB
2021.02.14 09:40:09 5: usbmaster, restore hash for 019AD4380B000097
2021.02.14 09:40:09 5: usbmaster, restore hash for 01E5D9370B00005D
2021.02.14 09:40:09 3: Setting usbmaster serial parameters to 38400,8,N,1
2021.02.14 09:40:09 5: usbmaster, DoInit
2021.02.14 09:40:09 4: usbmaster, SimpleWrite: $L+
$?
2021.02.14 09:40:09 1: /dev/ttyUSB0 reappeared (usbmaster)
2021.02.14 09:40:09 0: Featurelevel: 6
2021.02.14 09:40:09 0: Server started with 86 defined entities (fhem.pl:23613/2021-01-25 perl:5.024001 os:linux user:fhem pid:23439)
2021.02.14 09:40:09 3: telnetForBlockingFn_1613292009: port 35959 opened
2021.02.14 09:40:09 3: DbLog logdb - Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2021.02.14 09:40:09 3: DbLog logdb - Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2021.02.14 09:40:14 5: usbmaster, GetUpdate
2021.02.14 09:40:14 4: usbmaster, SimpleWrite: $?
2021.02.14 09:40:14 1: /dev/ttyUSB0 disconnected, waiting to reappear (usbmaster)
2021.02.14 09:40:24 5: usbmaster, GetUpdate
2021.02.14 09:40:34 5: usbmaster, GetUpdate
2021.02.14 09:40:34 3: Setting usbmaster serial parameters to 38400,8,N,1
2021.02.14 09:40:34 5: usbmaster, DoInit
2021.02.14 09:40:34 4: usbmaster, SimpleWrite: $L+
$?
2021.02.14 09:40:34 1: /dev/ttyUSB0 reappeared (usbmaster)
2021.02.14 09:40:34 5: usbmaster, ReadFn RAW: $0;o;2832AD459210021 / buf :$0;o;2832AD459210021
2021.02.14 09:40:34 5: usbmaster, ReadFn RAW: $0;o;2832AD459210021
2021.02.14 09:40:34 5: usbmaster, ReadFn RAW: $0;o;2832AD4592100214;
$1;o;28069D45921802D7;
$2;o;28 / buf :4;
$1;o;28069D45921802D7;
$2;o;28
2021.02.14 09:40:34 4: usbmaster, read[1] : 0;o;2832AD4592100214;
2021.02.14 09:40:34 4: usbmaster, found name Stubenfussbodenlinksp for device [0] 2832AD4592100214
2021.02.14 09:40:34 4: usbmaster, read[2] : 1;o;28069D45921802D7;
2021.02.14 09:40:34 4: usbmaster, found name Stubenfussbodenrechtsp for device [1] 28069D45921802D7
2021.02.14 09:40:34 5: usbmaster, ReadFn RAW: $2;o;28
2021.02.14 09:40:34 5: usbmaster, ReadFn RAW: $2;o;2846794592180267;
$3;o;2803DC459 / buf :46794592180267;
$3;o;2803DC459
2021.02.14 09:40:34 4: usbmaster, read[1] : 2;o;2846794592180267;
2021.02.14 09:40:34 4: usbmaster, found name Stubenfussbodenrechts for device [2] 2846794592180267
2021.02.14 09:40:34 5: usbmaster, ReadFn RAW: $3;o;2803DC459
2021.02.14 09:40:34 5: usbmaster, ReadFn RAW: $3;o;2803DC4592150291;
$4;o;019AD4380B0000 / buf :2150291;
$4;o;019AD4380B0000
2021.02.14 09:40:34 4: usbmaster, read[1] : 3;o;2803DC4592150291;
2021.02.14 09:40:34 4: usbmaster, found name Stubenfussbodenlinks for device [3] 2803DC4592150291
2021.02.14 09:40:34 5: usbmaster, ReadFn RAW: $4;o;019AD4380B0000
2021.02.14 09:40:34 5: usbmaster, ReadFn RAW: $4;o;019AD4380B000097;
$5;o;0196553A0B0000EB;
$S / buf :97;
$5;o;0196553A0B0000EB;
$S
2021.02.14 09:40:34 4: usbmaster, read[1] : 4;o;019AD4380B000097;
2021.02.14 09:40:34 4: usbmaster, found name Testlinks for device [4] 019AD4380B000097
2021.02.14 09:40:34 4: usbmaster, read[2] : 5;o;0196553A0B0000EB;
2021.02.14 09:40:34 4: usbmaster, found name Rauchalarm for device [5] 0196553A0B0000EB
2021.02.14 09:40:34 5: usbmaster, ReadFn RAW: $S
2021.02.14 09:40:34 5: usbmaster, ReadFn RAW: $S0;73;0
/ buf :0;73;0
2021.02.14 09:40:34 4: usbmaster, read[1] : S0;73;0
2021.02.14 09:40:34 5: usbmaster, UpdateReadings data : S0 73 0
2021.02.14 09:40:34 5: usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:40:34 5: ParseFn, OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:40:34 5: usbmaster: dispatch OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:40:34 5: ParseFn, OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:40:34 5: usbmaster: dispatch OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:40:34 5: ParseFn, OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:40:34 5: usbmaster: dispatch OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:40:34 5: ParseFn, OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:40:34 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:35 5: usbmaster, GetUpdate
2021.02.14 09:40:35 4: usbmaster, SimpleWrite: $?
2021.02.14 09:40:35 5: usbmaster, ReadFn RAW: $0;o;2832AD4592100214;
/ buf :$0;o;2832AD4592100214;
2021.02.14 09:40:35 4: usbmaster, read[1] : 0;o;2832AD4592100214;
2021.02.14 09:40:35 4: usbmaster, found name Stubenfussbodenlinksp for device [0] 2832AD4592100214
2021.02.14 09:40:35 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:35 5: usbmaster, ReadFn RAW: $1;o;28069D45921802D7;
$2;o;2846794592180267;
$3;o;2803DC4592150291;
$4;o;019AD4380B000097;
$5;o;0196553A0B0000EB;
$S0;73;0
/ buf :$1;o;28069D45921802D7;
$2;o;2846794592180267;
$3;o;2803DC4592150291;
$4;o;019AD4380B000097;
$5;o;0196553A0B0000EB;
$S0;73;0
2021.02.14 09:40:35 4: usbmaster, read[1] : 1;o;28069D45921802D7;
2021.02.14 09:40:35 4: usbmaster, found name Stubenfussbodenrechtsp for device [1] 28069D45921802D7
2021.02.14 09:40:35 4: usbmaster, read[2] : 2;o;2846794592180267;
2021.02.14 09:40:35 4: usbmaster, found name Stubenfussbodenrechts for device [2] 2846794592180267
2021.02.14 09:40:35 4: usbmaster, read[3] : 3;o;2803DC4592150291;
2021.02.14 09:40:35 4: usbmaster, found name Stubenfussbodenlinks for device [3] 2803DC4592150291
2021.02.14 09:40:35 4: usbmaster, read[4] : 4;o;019AD4380B000097;
2021.02.14 09:40:35 4: usbmaster, found name Testlinks for device [4] 019AD4380B000097
2021.02.14 09:40:35 4: usbmaster, read[5] : 5;o;0196553A0B0000EB;
2021.02.14 09:40:35 4: usbmaster, found name Rauchalarm for device [5] 0196553A0B0000EB
2021.02.14 09:40:35 4: usbmaster, read[6] : S0;73;0
2021.02.14 09:40:35 5: usbmaster, UpdateReadings data : S0 73 0
2021.02.14 09:40:35 5: usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:40:35 5: ParseFn, OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:40:35 5: usbmaster: dispatch OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:40:35 5: ParseFn, OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:40:35 5: usbmaster: dispatch OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:40:35 5: ParseFn, OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:40:35 5: usbmaster: dispatch OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:40:35 5: ParseFn, OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:40:35 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:35 4: usbmaster, SimpleWrite: $0
2021.02.14 09:40:35 5: usbmaster, read_OW : 0
2021.02.14 09:40:35 5: usbmaster, ReadFn RAW: $0 / buf :$0
2021.02.14 09:40:35 5: usbmaster, ReadFn RAW: $0
2021.02.14 09:40:35 5: usbmaster, ReadFn RAW: $0;o;ED;01;55;05;7F;7E;81;66;5F;8B;
/ buf :;o;ED;01;55;05;7F;7E;81;66;5F;8B;
2021.02.14 09:40:35 4: usbmaster, read[1] : 0;o;ED;01;55;05;7F;7E;81;66;5F;8B;
2021.02.14 09:40:35 5: usbmaster: dispatch OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:40:35 5: ParseFn, OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:40:35 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:36 4: usbmaster, SimpleWrite: $1
2021.02.14 09:40:36 5: usbmaster, read_OW : 1
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW: $1;o;E2;01;55;05;7F;7E;81; / buf :$1;o;E2;01;55;05;7F;7E;81;
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW: $1;o;E2;01;55;05;7F;7E;81;
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW: $1;o;E2;01;55;05;7F;7E;81;66;A5;C6;
/ buf :66;A5;C6;
2021.02.14 09:40:36 4: usbmaster, read[1] : 1;o;E2;01;55;05;7F;7E;81;66;A5;C6;
2021.02.14 09:40:36 5: usbmaster: dispatch OW,28069D45921802D7,DS18B20,30.1,1
2021.02.14 09:40:36 5: ParseFn, OW,28069D45921802D7,DS18B20,30.1,1
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:36 4: usbmaster, SimpleWrite: $0
2021.02.14 09:40:36 5: usbmaster, read_OW : 0
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW: $0;o;ED;01;55;05;7F; / buf :$0;o;ED;01;55;05;7F;
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW: $0;o;ED;01;55;05;7F;
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW: $0;o;ED;01;55;05;7F;7E;81;66;5F;8B;
/ buf :7E;81;66;5F;8B;
2021.02.14 09:40:36 4: usbmaster, read[1] : 0;o;ED;01;55;05;7F;7E;81;66;5F;8B;
2021.02.14 09:40:36 5: usbmaster: dispatch OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:40:36 5: ParseFn, OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:36 4: usbmaster, SimpleWrite: $2
2021.02.14 09:40:36 5: usbmaster, read_OW : 2
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW: $2;o;02;02;55;05;7F; / buf :$2;o;02;02;55;05;7F;
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW: $2;o;02;02;55;05;7F;
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW: $2;o;02;02;55;05;7F;7E;81;66;91;D3;
/ buf :7E;81;66;91;D3;
2021.02.14 09:40:36 4: usbmaster, read[1] : 2;o;02;02;55;05;7F;7E;81;66;91;D3;
2021.02.14 09:40:36 5: usbmaster: dispatch OW,2846794592180267,DS18B20,32.1,2
2021.02.14 09:40:36 5: ParseFn, OW,2846794592180267,DS18B20,32.1,2
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:36 4: usbmaster, SimpleWrite: $1
2021.02.14 09:40:36 5: usbmaster, read_OW : 1
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW: $ / buf :$
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW: $
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW: $1;o;E2;01;55;05;7F;7E;81;66;A5;C6;
/ buf :1;o;E2;01;55;05;7F;7E;81;66;A5;C6;
2021.02.14 09:40:36 4: usbmaster, read[1] : 1;o;E2;01;55;05;7F;7E;81;66;A5;C6;
2021.02.14 09:40:36 5: usbmaster: dispatch OW,28069D45921802D7,DS18B20,30.1,1
2021.02.14 09:40:36 5: ParseFn, OW,28069D45921802D7,DS18B20,30.1,1
2021.02.14 09:40:36 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:37 4: usbmaster, SimpleWrite: $3
2021.02.14 09:40:37 5: usbmaster, read_OW : 3
2021.02.14 09:40:37 5: usbmaster, ReadFn RAW: $3;o;DA;01; / buf :$3;o;DA;01;
2021.02.14 09:40:37 5: usbmaster, ReadFn RAW: $3;o;DA;01;
2021.02.14 09:40:37 5: usbmaster, ReadFn RAW: $3;o;DA;01;55;05;7F;7E;81;66;73;8C;
/ buf :55;05;7F;7E;81;66;73;8C;
2021.02.14 09:40:37 4: usbmaster, read[1] : 3;o;DA;01;55;05;7F;7E;81;66;73;8C;
2021.02.14 09:40:37 5: usbmaster: dispatch OW,2803DC4592150291,DS18B20,29.6,3
2021.02.14 09:40:37 5: ParseFn, OW,2803DC4592150291,DS18B20,29.6,3
2021.02.14 09:40:37 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:37 4: usbmaster, SimpleWrite: $2
2021.02.14 09:40:37 5: usbmaster, read_OW : 2
2021.02.14 09:40:37 5: usbmaster, ReadFn RAW: $2;o;02;02;55;05;7F;7E;81; / buf :$2;o;02;02;55;05;7F;7E;81;
2021.02.14 09:40:37 5: usbmaster, ReadFn RAW: $2;o;02;02;55;05;7F;7E;81;
2021.02.14 09:40:37 5: usbmaster, ReadFn RAW: $2;o;02;02;55;05;7F;7E;81;66;91;D3;
/ buf :66;91;D3;
2021.02.14 09:40:37 4: usbmaster, read[1] : 2;o;02;02;55;05;7F;7E;81;66;91;D3;
2021.02.14 09:40:37 5: usbmaster: dispatch OW,2846794592180267,DS18B20,32.1,2
2021.02.14 09:40:37 5: ParseFn, OW,2846794592180267,DS18B20,32.1,2
2021.02.14 09:40:37 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:37 4: usbmaster, SimpleWrite: $3
2021.02.14 09:40:37 5: usbmaster, read_OW : 3
2021.02.14 09:40:37 5: usbmaster, ReadFn RAW: $3;o;DA;01; / buf :$3;o;DA;01;
2021.02.14 09:40:37 5: usbmaster, ReadFn RAW: $3;o;DA;01;
2021.02.14 09:40:37 5: usbmaster, ReadFn RAW: $3;o;DA;01;55;05;7F;7E;81;66;73;8C;
/ buf :55;05;7F;7E;81;66;73;8C;
2021.02.14 09:40:37 4: usbmaster, read[1] : 3;o;DA;01;55;05;7F;7E;81;66;73;8C;
2021.02.14 09:40:37 5: usbmaster: dispatch OW,2803DC4592150291,DS18B20,29.6,3
2021.02.14 09:40:37 5: ParseFn, OW,2803DC4592150291,DS18B20,29.6,3
2021.02.14 09:40:37 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:45 5: usbmaster, GetUpdate
2021.02.14 09:40:45 4: usbmaster, SimpleWrite: $?
2021.02.14 09:40:45 5: usbmaster, ReadFn RAW: $0;o;283 / buf :$0;o;283
2021.02.14 09:40:45 5: usbmaster, ReadFn RAW: $0;o;283
2021.02.14 09:40:45 5: usbmaster, ReadFn RAW: $0;o;2832AD4592100214;
$1;o;28069D4592 / buf :2AD4592100214;
$1;o;28069D4592
2021.02.14 09:40:45 4: usbmaster, read[1] : 0;o;2832AD4592100214;
2021.02.14 09:40:45 4: usbmaster, found name Stubenfussbodenlinksp for device [0] 2832AD4592100214
2021.02.14 09:40:45 5: usbmaster, ReadFn RAW: $1;o;28069D4592
2021.02.14 09:40:45 5: usbmaster, ReadFn RAW: $1;o;28069D45921802D7;
$2;o;2846794592180267;
/ buf :1802D7;
$2;o;2846794592180267;
2021.02.14 09:40:45 4: usbmaster, read[1] : 1;o;28069D45921802D7;
2021.02.14 09:40:45 4: usbmaster, found name Stubenfussbodenrechtsp for device [1] 28069D45921802D7
2021.02.14 09:40:45 4: usbmaster, read[2] : 2;o;2846794592180267;
2021.02.14 09:40:45 4: usbmaster, found name Stubenfussbodenrechts for device [2] 2846794592180267
2021.02.14 09:40:45 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:45 5: usbmaster, ReadFn RAW: $3;o;2803DC4592150291;
$4;o;01 / buf :$3;o;2803DC4592150291;
$4;o;01
2021.02.14 09:40:45 4: usbmaster, read[1] : 3;o;2803DC4592150291;
2021.02.14 09:40:45 4: usbmaster, found name Stubenfussbodenlinks for device [3] 2803DC4592150291
2021.02.14 09:40:45 5: usbmaster, ReadFn RAW: $4;o;01
2021.02.14 09:40:45 5: usbmaster, ReadFn RAW: $4;o;019AD4380B000097;
$5;o;0196553A / buf :9AD4380B000097;
$5;o;0196553A
2021.02.14 09:40:45 4: usbmaster, read[1] : 4;o;019AD4380B000097;
2021.02.14 09:40:45 4: usbmaster, found name Testlinks for device [4] 019AD4380B000097
2021.02.14 09:40:45 5: usbmaster, ReadFn RAW: $5;o;0196553A
2021.02.14 09:40:45 5: usbmaster, ReadFn RAW: $5;o;0196553A0B0000EB;
$S0;73;0
/ buf :0B0000EB;
$S0;73;0
2021.02.14 09:40:45 4: usbmaster, read[1] : 5;o;0196553A0B0000EB;
2021.02.14 09:40:45 4: usbmaster, found name Rauchalarm for device [5] 0196553A0B0000EB
2021.02.14 09:40:45 4: usbmaster, read[2] : S0;73;0
2021.02.14 09:40:45 5: usbmaster, UpdateReadings data : S0 73 0
2021.02.14 09:40:45 5: usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:40:45 5: ParseFn, OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:40:45 5: usbmaster: dispatch OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:40:45 5: ParseFn, OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:40:45 5: usbmaster: dispatch OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:40:45 5: ParseFn, OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:40:45 5: usbmaster: dispatch OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:40:45 5: ParseFn, OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:40:45 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:46 4: usbmaster, SimpleWrite: $0
2021.02.14 09:40:46 5: usbmaster, read_OW : 0
2021.02.14 09:40:46 5: usbmaster, ReadFn RAW: $ / buf :$
2021.02.14 09:40:46 5: usbmaster, ReadFn RAW: $
2021.02.14 09:40:46 5: usbmaster, ReadFn RAW: $0;o;EC;01;55;05;7F;7E;81;66;1C;47;
/ buf :0;o;EC;01;55;05;7F;7E;81;66;1C;47;
2021.02.14 09:40:46 4: usbmaster, read[1] : 0;o;EC;01;55;05;7F;7E;81;66;1C;47;
2021.02.14 09:40:46 5: usbmaster: dispatch OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:40:46 5: ParseFn, OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:40:46 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:46 4: usbmaster, SimpleWrite: $1
2021.02.14 09:40:46 5: usbmaster, read_OW : 1
2021.02.14 09:40:46 5: usbmaster, ReadFn RAW: $1;o;E2;01;55;05;7F;7E;81;6 / buf :$1;o;E2;01;55;05;7F;7E;81;6
2021.02.14 09:40:46 5: usbmaster, ReadFn RAW: $1;o;E2;01;55;05;7F;7E;81;6
2021.02.14 09:40:46 5: usbmaster, ReadFn RAW: $1;o;E2;01;55;05;7F;7E;81;66;A5;C6;
/ buf :6;A5;C6;
2021.02.14 09:40:46 4: usbmaster, read[1] : 1;o;E2;01;55;05;7F;7E;81;66;A5;C6;
2021.02.14 09:40:46 5: usbmaster: dispatch OW,28069D45921802D7,DS18B20,30.1,1
2021.02.14 09:40:46 5: ParseFn, OW,28069D45921802D7,DS18B20,30.1,1
2021.02.14 09:40:46 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:47 4: usbmaster, SimpleWrite: $2
2021.02.14 09:40:47 5: usbmaster, read_OW : 2
2021.02.14 09:40:47 5: usbmaster, ReadFn RAW: $2;o;00;02 / buf :$2;o;00;02
2021.02.14 09:40:47 5: usbmaster, ReadFn RAW: $2;o;00;02
2021.02.14 09:40:47 5: usbmaster, ReadFn RAW: $2;o;00;02;55;05;7F;7E;81;66;17;57;
/ buf :;55;05;7F;7E;81;66;17;57;
2021.02.14 09:40:47 4: usbmaster, read[1] : 2;o;00;02;55;05;7F;7E;81;66;17;57;
2021.02.14 09:40:47 5: usbmaster: dispatch OW,2846794592180267,DS18B20,32.0,2
2021.02.14 09:40:47 5: ParseFn, OW,2846794592180267,DS18B20,32.0,2
2021.02.14 09:40:47 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:47 4: usbmaster, SimpleWrite: $3
2021.02.14 09:40:47 5: usbmaster, read_OW : 3
2021.02.14 09:40:47 5: usbmaster, ReadFn RAW: $3;o;DB; / buf :$3;o;DB;
2021.02.14 09:40:47 5: usbmaster, ReadFn RAW: $3;o;DB;
2021.02.14 09:40:47 5: usbmaster, ReadFn RAW: $3;o;DB;01;55;05;7F;7E;81;66;30;4A;
/ buf :01;55;05;7F;7E;81;66;30;4A;
2021.02.14 09:40:47 4: usbmaster, read[1] : 3;o;DB;01;55;05;7F;7E;81;66;30;4A;
2021.02.14 09:40:47 5: usbmaster: dispatch OW,2803DC4592150291,DS18B20,29.7,3
2021.02.14 09:40:47 5: ParseFn, OW,2803DC4592150291,DS18B20,29.7,3
2021.02.14 09:40:47 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:55 5: usbmaster, GetUpdate
2021.02.14 09:40:55 4: usbmaster, SimpleWrite: $?
2021.02.14 09:40:55 5: usbmaster, ReadFn RAW: $0;o;2832AD45921002 / buf :$0;o;2832AD45921002
2021.02.14 09:40:55 5: usbmaster, ReadFn RAW: $0;o;2832AD45921002
2021.02.14 09:40:55 5: usbmaster, ReadFn RAW: $0;o;2832AD4592100214;
$1;o;28069D45921802D7;
$2;o; / buf :14;
$1;o;28069D45921802D7;
$2;o;
2021.02.14 09:40:55 4: usbmaster, read[1] : 0;o;2832AD4592100214;
2021.02.14 09:40:55 4: usbmaster, found name Stubenfussbodenlinksp for device [0] 2832AD4592100214
2021.02.14 09:40:55 4: usbmaster, read[2] : 1;o;28069D45921802D7;
2021.02.14 09:40:55 4: usbmaster, found name Stubenfussbodenrechtsp for device [1] 28069D45921802D7
2021.02.14 09:40:55 5: usbmaster, ReadFn RAW: $2;o;
2021.02.14 09:40:55 5: usbmaster, ReadFn RAW: $2;o;2846794592180267;
$3;o;2803DC4 / buf :2846794592180267;
$3;o;2803DC4
2021.02.14 09:40:55 4: usbmaster, read[1] : 2;o;2846794592180267;
2021.02.14 09:40:55 4: usbmaster, found name Stubenfussbodenrechts for device [2] 2846794592180267
2021.02.14 09:40:55 5: usbmaster, ReadFn RAW: $3;o;2803DC4
2021.02.14 09:40:55 5: usbmaster, ReadFn RAW: $3;o;2803DC4592150291;
$4;o;019AD4380B00 / buf :592150291;
$4;o;019AD4380B00
2021.02.14 09:40:55 4: usbmaster, read[1] : 3;o;2803DC4592150291;
2021.02.14 09:40:55 4: usbmaster, found name Stubenfussbodenlinks for device [3] 2803DC4592150291
2021.02.14 09:40:55 5: usbmaster, ReadFn RAW: $4;o;019AD4380B00
2021.02.14 09:40:55 5: usbmaster, ReadFn RAW: $4;o;019AD4380B000097;
$5;o;0196553A0B0000EB;
/ buf :0097;
$5;o;0196553A0B0000EB;
2021.02.14 09:40:55 4: usbmaster, read[1] : 4;o;019AD4380B000097;
2021.02.14 09:40:55 4: usbmaster, found name Testlinks for device [4] 019AD4380B000097
2021.02.14 09:40:55 4: usbmaster, read[2] : 5;o;0196553A0B0000EB;
2021.02.14 09:40:55 4: usbmaster, found name Rauchalarm for device [5] 0196553A0B0000EB
2021.02.14 09:40:55 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:55 5: usbmaster, ReadFn RAW: $S0;73;0
/ buf :$S0;73;0
2021.02.14 09:40:55 4: usbmaster, read[1] : S0;73;0
2021.02.14 09:40:55 5: usbmaster, UpdateReadings data : S0 73 0
2021.02.14 09:40:55 5: usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:40:55 5: ParseFn, OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:40:55 5: usbmaster: dispatch OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:40:55 5: ParseFn, OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:40:55 5: usbmaster: dispatch OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:40:55 5: ParseFn, OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:40:55 5: usbmaster: dispatch OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:40:55 5: ParseFn, OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:40:55 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:56 4: usbmaster, SimpleWrite: $0
2021.02.14 09:40:56 5: usbmaster, read_OW : 0
2021.02.14 09:40:56 5: usbmaster, ReadFn RAW: $ / buf :$
2021.02.14 09:40:56 5: usbmaster, ReadFn RAW: $
2021.02.14 09:40:56 5: usbmaster, ReadFn RAW: $0;o;EC;01;55;05;7F;7E;81;66;1C;47;
/ buf :0;o;EC;01;55;05;7F;7E;81;66;1C;47;
2021.02.14 09:40:56 4: usbmaster, read[1] : 0;o;EC;01;55;05;7F;7E;81;66;1C;47;
2021.02.14 09:40:56 5: usbmaster: dispatch OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:40:56 5: ParseFn, OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:40:56 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:56 4: usbmaster, SimpleWrite: $1
2021.02.14 09:40:56 5: usbmaster, read_OW : 1
2021.02.14 09:40:56 5: usbmaster, ReadFn RAW: $1;o;E3;01;55;05;7F;7E;81 / buf :$1;o;E3;01;55;05;7F;7E;81
2021.02.14 09:40:56 5: usbmaster, ReadFn RAW: $1;o;E3;01;55;05;7F;7E;81
2021.02.14 09:40:56 5: usbmaster, ReadFn RAW: $1;o;E3;01;55;05;7F;7E;81;66;E6;08;
/ buf :;66;E6;08;
2021.02.14 09:40:56 4: usbmaster, read[1] : 1;o;E3;01;55;05;7F;7E;81;66;E6;08;
2021.02.14 09:40:56 5: usbmaster: dispatch OW,28069D45921802D7,DS18B20,30.2,1
2021.02.14 09:40:56 5: ParseFn, OW,28069D45921802D7,DS18B20,30.2,1
2021.02.14 09:40:56 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:57 4: usbmaster, SimpleWrite: $2
2021.02.14 09:40:57 5: usbmaster, read_OW : 2
2021.02.14 09:40:57 5: usbmaster, ReadFn RAW: $2;o;04;02;55;05;7 / buf :$2;o;04;02;55;05;7
2021.02.14 09:40:57 5: usbmaster, ReadFn RAW: $2;o;04;02;55;05;7
2021.02.14 09:40:57 5: usbmaster, ReadFn RAW: $2;o;04;02;55;05;7F;7E;81;66;02;46;
/ buf :F;7E;81;66;02;46;
2021.02.14 09:40:57 4: usbmaster, read[1] : 2;o;04;02;55;05;7F;7E;81;66;02;46;
2021.02.14 09:40:57 5: usbmaster: dispatch OW,2846794592180267,DS18B20,32.2,2
2021.02.14 09:40:57 5: ParseFn, OW,2846794592180267,DS18B20,32.2,2
2021.02.14 09:40:57 5: usbmaster, ReadFn RAW:
2021.02.14 09:40:57 4: usbmaster, SimpleWrite: $3
2021.02.14 09:40:57 5: usbmaster, read_OW : 3
2021.02.14 09:40:57 5: usbmaster, ReadFn RAW: $3;o;DB;0 / buf :$3;o;DB;0
2021.02.14 09:40:57 5: usbmaster, ReadFn RAW: $3;o;DB;0
2021.02.14 09:40:57 5: usbmaster, ReadFn RAW: $3;o;DB;01;55;05;7F;7E;81;66;30;4A;
/ buf :1;55;05;7F;7E;81;66;30;4A;
2021.02.14 09:40:57 4: usbmaster, read[1] : 3;o;DB;01;55;05;7F;7E;81;66;30;4A;
2021.02.14 09:40:57 5: usbmaster: dispatch OW,2803DC4592150291,DS18B20,29.7,3
2021.02.14 09:40:57 5: ParseFn, OW,2803DC4592150291,DS18B20,29.7,3
2021.02.14 09:40:57 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:05 5: usbmaster, GetUpdate
2021.02.14 09:41:05 4: usbmaster, SimpleWrite: $?
2021.02.14 09:41:05 5: usbmaster, ReadFn RAW: $0;o; / buf :$0;o;
2021.02.14 09:41:05 5: usbmaster, ReadFn RAW: $0;o;
2021.02.14 09:41:05 5: usbmaster, ReadFn RAW: $0;o;2832AD4592100214;
$1;o;28069D45 / buf :2832AD4592100214;
$1;o;28069D45
2021.02.14 09:41:05 4: usbmaster, read[1] : 0;o;2832AD4592100214;
2021.02.14 09:41:05 4: usbmaster, found name Stubenfussbodenlinksp for device [0] 2832AD4592100214
2021.02.14 09:41:05 5: usbmaster, ReadFn RAW: $1;o;28069D45
2021.02.14 09:41:05 5: usbmaster, ReadFn RAW: $1;o;28069D45921802D7;
$2;o;28467945921802 / buf :921802D7;
$2;o;28467945921802
2021.02.14 09:41:05 4: usbmaster, read[1] : 1;o;28069D45921802D7;
2021.02.14 09:41:05 4: usbmaster, found name Stubenfussbodenrechtsp for device [1] 28069D45921802D7
2021.02.14 09:41:05 5: usbmaster, ReadFn RAW: $2;o;28467945921802
2021.02.14 09:41:05 5: usbmaster, ReadFn RAW: $2;o;2846794592180267;
$3;o;2803DC4592150291;
$4; / buf :67;
$3;o;2803DC4592150291;
$4;
2021.02.14 09:41:05 4: usbmaster, read[1] : 2;o;2846794592180267;
2021.02.14 09:41:05 4: usbmaster, found name Stubenfussbodenrechts for device [2] 2846794592180267
2021.02.14 09:41:05 4: usbmaster, read[2] : 3;o;2803DC4592150291;
2021.02.14 09:41:05 4: usbmaster, found name Stubenfussbodenlinks for device [3] 2803DC4592150291
2021.02.14 09:41:05 5: usbmaster, ReadFn RAW: $4;
2021.02.14 09:41:05 5: usbmaster, ReadFn RAW: $4;o;019AD4380B000097;
$5;o;019655 / buf :o;019AD4380B000097;
$5;o;019655
2021.02.14 09:41:05 4: usbmaster, read[1] : 4;o;019AD4380B000097;
2021.02.14 09:41:05 4: usbmaster, found name Testlinks for device [4] 019AD4380B000097
2021.02.14 09:41:05 5: usbmaster, ReadFn RAW: $5;o;019655
2021.02.14 09:41:05 5: usbmaster, ReadFn RAW: $5;o;0196553A0B0000EB;
$S0;73;0
/ buf :3A0B0000EB;
$S0;73;0
2021.02.14 09:41:05 4: usbmaster, read[1] : 5;o;0196553A0B0000EB;
2021.02.14 09:41:05 4: usbmaster, found name Rauchalarm for device [5] 0196553A0B0000EB
2021.02.14 09:41:05 4: usbmaster, read[2] : S0;73;0
2021.02.14 09:41:05 5: usbmaster, UpdateReadings data : S0 73 0
2021.02.14 09:41:05 5: usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:41:05 5: ParseFn, OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:41:05 5: usbmaster: dispatch OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:41:05 5: ParseFn, OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:41:05 5: usbmaster: dispatch OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:41:05 5: ParseFn, OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:41:05 5: usbmaster: dispatch OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:41:05 5: ParseFn, OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:41:05 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:06 4: usbmaster, SimpleWrite: $0
2021.02.14 09:41:06 5: usbmaster, read_OW : 0
2021.02.14 09:41:06 5: usbmaster, ReadFn RAW: $ / buf :$
2021.02.14 09:41:06 5: usbmaster, ReadFn RAW: $
2021.02.14 09:41:06 5: usbmaster, ReadFn RAW: $0;o;ED;01;55;05;7F;7E;81;66;5F;8B;
/ buf :0;o;ED;01;55;05;7F;7E;81;66;5F;8B;
2021.02.14 09:41:06 4: usbmaster, read[1] : 0;o;ED;01;55;05;7F;7E;81;66;5F;8B;
2021.02.14 09:41:06 5: usbmaster: dispatch OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:41:06 5: ParseFn, OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:41:06 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:06 4: usbmaster, SimpleWrite: $1
2021.02.14 09:41:06 5: usbmaster, read_OW : 1
2021.02.14 09:41:06 5: usbmaster, ReadFn RAW: $1;o;E3;01;55;05;7F;7E;81; / buf :$1;o;E3;01;55;05;7F;7E;81;
2021.02.14 09:41:06 5: usbmaster, ReadFn RAW: $1;o;E3;01;55;05;7F;7E;81;
2021.02.14 09:41:06 5: usbmaster, ReadFn RAW: $1;o;E3;01;55;05;7F;7E;81;66;E6;08;
/ buf :66;E6;08;
2021.02.14 09:41:06 4: usbmaster, read[1] : 1;o;E3;01;55;05;7F;7E;81;66;E6;08;
2021.02.14 09:41:06 5: usbmaster: dispatch OW,28069D45921802D7,DS18B20,30.2,1
2021.02.14 09:41:06 5: ParseFn, OW,28069D45921802D7,DS18B20,30.2,1
2021.02.14 09:41:06 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:07 4: usbmaster, SimpleWrite: $2
2021.02.14 09:41:07 5: usbmaster, read_OW : 2
2021.02.14 09:41:07 5: usbmaster, ReadFn RAW: $2;o;01;02;55;05;7F;7 / buf :$2;o;01;02;55;05;7F;7
2021.02.14 09:41:07 5: usbmaster, ReadFn RAW: $2;o;01;02;55;05;7F;7
2021.02.14 09:41:07 5: usbmaster, ReadFn RAW: $2;o;01;02;55;05;7F;7E;81;66;54;95;
/ buf :E;81;66;54;95;
2021.02.14 09:41:07 4: usbmaster, read[1] : 2;o;01;02;55;05;7F;7E;81;66;54;95;
2021.02.14 09:41:07 5: usbmaster: dispatch OW,2846794592180267,DS18B20,32.1,2
2021.02.14 09:41:07 5: ParseFn, OW,2846794592180267,DS18B20,32.1,2
2021.02.14 09:41:07 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:09 4: usbmaster, SimpleWrite: $3
2021.02.14 09:41:09 5: usbmaster, read_OW : 3
2021.02.14 09:41:09 5: usbmaster, ReadFn RAW: $3;o;DA;01;55;05;7F;7E;81;66;73;8C;
/ buf :$3;o;DA;01;55;05;7F;7E;81;66;73;8C;
2021.02.14 09:41:09 4: usbmaster, read[1] : 3;o;DA;01;55;05;7F;7E;81;66;73;8C;
2021.02.14 09:41:09 5: usbmaster: dispatch OW,2803DC4592150291,DS18B20,29.6,3
2021.02.14 09:41:09 5: ParseFn, OW,2803DC4592150291,DS18B20,29.6,3
2021.02.14 09:41:09 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:15 5: usbmaster, GetUpdate
2021.02.14 09:41:15 4: usbmaster, SimpleWrite: $?
2021.02.14 09:41:15 5: usbmaster, ReadFn RAW: $0;o;2832AD459210 / buf :$0;o;2832AD459210
2021.02.14 09:41:15 5: usbmaster, ReadFn RAW: $0;o;2832AD459210
2021.02.14 09:41:15 5: usbmaster, ReadFn RAW: $0;o;2832AD4592100214;
$1;o;28069D45921802D7;
/ buf :0214;
$1;o;28069D45921802D7;
2021.02.14 09:41:15 4: usbmaster, read[1] : 0;o;2832AD4592100214;
2021.02.14 09:41:15 4: usbmaster, found name Stubenfussbodenlinksp for device [0] 2832AD4592100214
2021.02.14 09:41:15 4: usbmaster, read[2] : 1;o;28069D45921802D7;
2021.02.14 09:41:15 4: usbmaster, found name Stubenfussbodenrechtsp for device [1] 28069D45921802D7
2021.02.14 09:41:15 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:15 5: usbmaster, ReadFn RAW: $2;o;2846794592180267;
$3;o;2803 / buf :$2;o;2846794592180267;
$3;o;2803
2021.02.14 09:41:15 4: usbmaster, read[1] : 2;o;2846794592180267;
2021.02.14 09:41:15 4: usbmaster, found name Stubenfussbodenrechts for device [2] 2846794592180267
2021.02.14 09:41:15 5: usbmaster, ReadFn RAW: $3;o;2803
2021.02.14 09:41:15 5: usbmaster, ReadFn RAW: $3;o;2803DC4592150291;
$4;o;019AD4380B / buf :DC4592150291;
$4;o;019AD4380B
2021.02.14 09:41:15 4: usbmaster, read[1] : 3;o;2803DC4592150291;
2021.02.14 09:41:15 4: usbmaster, found name Stubenfussbodenlinks for device [3] 2803DC4592150291
2021.02.14 09:41:15 5: usbmaster, ReadFn RAW: $4;o;019AD4380B
2021.02.14 09:41:15 5: usbmaster, ReadFn RAW: $4;o;019AD4380B000097;
$5;o;0196553A0B0000E / buf :000097;
$5;o;0196553A0B0000E
2021.02.14 09:41:15 4: usbmaster, read[1] : 4;o;019AD4380B000097;
2021.02.14 09:41:15 4: usbmaster, found name Testlinks for device [4] 019AD4380B000097
2021.02.14 09:41:15 5: usbmaster, ReadFn RAW: $5;o;0196553A0B0000E
2021.02.14 09:41:15 5: usbmaster, ReadFn RAW: $5;o;0196553A0B0000EB;
$S0;73;0
/ buf :B;
$S0;73;0
2021.02.14 09:41:15 4: usbmaster, read[1] : 5;o;0196553A0B0000EB;
2021.02.14 09:41:15 4: usbmaster, found name Rauchalarm for device [5] 0196553A0B0000EB
2021.02.14 09:41:15 4: usbmaster, read[2] : S0;73;0
2021.02.14 09:41:15 5: usbmaster, UpdateReadings data : S0 73 0
2021.02.14 09:41:15 5: usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:41:15 5: ParseFn, OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:41:15 5: usbmaster: dispatch OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:41:15 5: ParseFn, OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:41:15 5: usbmaster: dispatch OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:41:15 5: ParseFn, OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:41:15 5: usbmaster: dispatch OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:41:15 5: ParseFn, OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:41:15 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:16 4: usbmaster, SimpleWrite: $0
2021.02.14 09:41:16 5: usbmaster, read_OW : 0
2021.02.14 09:41:16 5: usbmaster, ReadFn RAW: $ / buf :$
2021.02.14 09:41:16 5: usbmaster, ReadFn RAW: $
2021.02.14 09:41:16 5: usbmaster, ReadFn RAW: $0;o;EC;01;55;05;7F;7E;81;66;1C;47;
/ buf :0;o;EC;01;55;05;7F;7E;81;66;1C;47;
2021.02.14 09:41:16 4: usbmaster, read[1] : 0;o;EC;01;55;05;7F;7E;81;66;1C;47;
2021.02.14 09:41:16 5: usbmaster: dispatch OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:41:16 5: ParseFn, OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:41:16 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:16 4: usbmaster, SimpleWrite: $1
2021.02.14 09:41:16 5: usbmaster, read_OW : 1
2021.02.14 09:41:16 5: usbmaster, ReadFn RAW: $1;o;E3;01;55;05;7F;7E;81; / buf :$1;o;E3;01;55;05;7F;7E;81;
2021.02.14 09:41:16 5: usbmaster, ReadFn RAW: $1;o;E3;01;55;05;7F;7E;81;
2021.02.14 09:41:16 5: usbmaster, ReadFn RAW: $1;o;E3;01;55;05;7F;7E;81;66;E6;08;
/ buf :66;E6;08;
2021.02.14 09:41:16 4: usbmaster, read[1] : 1;o;E3;01;55;05;7F;7E;81;66;E6;08;
2021.02.14 09:41:16 5: usbmaster: dispatch OW,28069D45921802D7,DS18B20,30.2,1
2021.02.14 09:41:16 5: ParseFn, OW,28069D45921802D7,DS18B20,30.2,1
2021.02.14 09:41:16 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:17 4: usbmaster, SimpleWrite: $2
2021.02.14 09:41:17 5: usbmaster, read_OW : 2
2021.02.14 09:41:17 5: usbmaster, ReadFn RAW: $2;o;01;02;55;05; / buf :$2;o;01;02;55;05;
2021.02.14 09:41:17 5: usbmaster, ReadFn RAW: $2;o;01;02;55;05;
2021.02.14 09:41:17 5: usbmaster, ReadFn RAW: $2;o;01;02;55;05;7F;7E;81;66;54;95;
/ buf :7F;7E;81;66;54;95;
2021.02.14 09:41:17 4: usbmaster, read[1] : 2;o;01;02;55;05;7F;7E;81;66;54;95;
2021.02.14 09:41:17 5: usbmaster: dispatch OW,2846794592180267,DS18B20,32.1,2
2021.02.14 09:41:17 5: ParseFn, OW,2846794592180267,DS18B20,32.1,2
2021.02.14 09:41:17 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:17 4: usbmaster, SimpleWrite: $3
2021.02.14 09:41:17 5: usbmaster, read_OW : 3
2021.02.14 09:41:17 5: usbmaster, ReadFn RAW: $3;o;DB; / buf :$3;o;DB;
2021.02.14 09:41:17 5: usbmaster, ReadFn RAW: $3;o;DB;
2021.02.14 09:41:17 5: usbmaster, ReadFn RAW: $3;o;DB;01;55;05;7F;7E;81;66;30;4A;
/ buf :01;55;05;7F;7E;81;66;30;4A;
2021.02.14 09:41:17 4: usbmaster, read[1] : 3;o;DB;01;55;05;7F;7E;81;66;30;4A;
2021.02.14 09:41:17 5: usbmaster: dispatch OW,2803DC4592150291,DS18B20,29.7,3
2021.02.14 09:41:17 5: ParseFn, OW,2803DC4592150291,DS18B20,29.7,3
2021.02.14 09:41:17 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:25 5: usbmaster, GetUpdate
2021.02.14 09:41:25 4: usbmaster, SimpleWrite: $?
2021.02.14 09:41:25 5: usbmaster, ReadFn RAW: $0;o;2832AD4592100214;
$1;o;28 / buf :$0;o;2832AD4592100214;
$1;o;28
2021.02.14 09:41:25 4: usbmaster, read[1] : 0;o;2832AD4592100214;
2021.02.14 09:41:25 4: usbmaster, found name Stubenfussbodenlinksp for device [0] 2832AD4592100214
2021.02.14 09:41:25 5: usbmaster, ReadFn RAW: $1;o;28
2021.02.14 09:41:25 5: usbmaster, ReadFn RAW: $1;o;28069D45921802D7;
$2;o;28467945 / buf :069D45921802D7;
$2;o;28467945
2021.02.14 09:41:25 4: usbmaster, read[1] : 1;o;28069D45921802D7;
2021.02.14 09:41:25 4: usbmaster, found name Stubenfussbodenrechtsp for device [1] 28069D45921802D7
2021.02.14 09:41:25 5: usbmaster, ReadFn RAW: $2;o;28467945
2021.02.14 09:41:25 5: usbmaster, ReadFn RAW: $2;o;2846794592180267;
$3;o;2803DC459215029 / buf :92180267;
$3;o;2803DC459215029
2021.02.14 09:41:25 4: usbmaster, read[1] : 2;o;2846794592180267;
2021.02.14 09:41:25 4: usbmaster, found name Stubenfussbodenrechts for device [2] 2846794592180267
2021.02.14 09:41:25 5: usbmaster, ReadFn RAW: $3;o;2803DC459215029
2021.02.14 09:41:25 5: usbmaster, ReadFn RAW: $3;o;2803DC4592150291;
$4;o;019AD4380B000097;
$5;o / buf :1;
$4;o;019AD4380B000097;
$5;o
2021.02.14 09:41:25 4: usbmaster, read[1] : 3;o;2803DC4592150291;
2021.02.14 09:41:25 4: usbmaster, found name Stubenfussbodenlinks for device [3] 2803DC4592150291
2021.02.14 09:41:25 4: usbmaster, read[2] : 4;o;019AD4380B000097;
2021.02.14 09:41:25 4: usbmaster, found name Testlinks for device [4] 019AD4380B000097
2021.02.14 09:41:25 5: usbmaster, ReadFn RAW: $5;o
2021.02.14 09:41:25 5: usbmaster, ReadFn RAW: $5;o;0196553A0B0000EB;
$S0;73; / buf :;0196553A0B0000EB;
$S0;73;
2021.02.14 09:41:25 4: usbmaster, read[1] : 5;o;0196553A0B0000EB;
2021.02.14 09:41:25 4: usbmaster, found name Rauchalarm for device [5] 0196553A0B0000EB
2021.02.14 09:41:25 5: usbmaster, ReadFn RAW: $S0;73;
2021.02.14 09:41:25 5: usbmaster, ReadFn RAW: $S0;73;0
/ buf :0
2021.02.14 09:41:25 4: usbmaster, read[1] : S0;73;0
2021.02.14 09:41:25 5: usbmaster, UpdateReadings data : S0 73 0
2021.02.14 09:41:25 5: usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:41:25 5: ParseFn, OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:41:25 5: usbmaster: dispatch OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:41:25 5: ParseFn, OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:41:25 5: usbmaster: dispatch OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:41:25 5: ParseFn, OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:41:25 5: usbmaster: dispatch OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:41:25 5: ParseFn, OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:41:25 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:26 4: usbmaster, SimpleWrite: $0
2021.02.14 09:41:26 5: usbmaster, read_OW : 0
2021.02.14 09:41:26 5: usbmaster, ReadFn RAW: $ / buf :$
2021.02.14 09:41:26 5: usbmaster, ReadFn RAW: $
2021.02.14 09:41:26 5: usbmaster, ReadFn RAW: $0;o;EC;01;55;05;7F;7E;81;66;1C;47;
/ buf :0;o;EC;01;55;05;7F;7E;81;66;1C;47;
2021.02.14 09:41:26 4: usbmaster, read[1] : 0;o;EC;01;55;05;7F;7E;81;66;1C;47;
2021.02.14 09:41:26 5: usbmaster: dispatch OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:41:26 5: ParseFn, OW,2832AD4592100214,DS18B20,30.8,0
2021.02.14 09:41:26 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:26 4: usbmaster, SimpleWrite: $1
2021.02.14 09:41:26 5: usbmaster, read_OW : 1
2021.02.14 09:41:26 5: usbmaster, ReadFn RAW: $1;o;E1;01;55;05;7F;7E;81;66;6 / buf :$1;o;E1;01;55;05;7F;7E;81;66;6
2021.02.14 09:41:26 5: usbmaster, ReadFn RAW: $1;o;E1;01;55;05;7F;7E;81;66;6
2021.02.14 09:41:26 5: usbmaster, ReadFn RAW: $1;o;E1;01;55;05;7F;7E;81;66;60;80;
/ buf :0;80;
2021.02.14 09:41:26 4: usbmaster, read[1] : 1;o;E1;01;55;05;7F;7E;81;66;60;80;
2021.02.14 09:41:26 5: usbmaster: dispatch OW,28069D45921802D7,DS18B20,30.1,1
2021.02.14 09:41:26 5: ParseFn, OW,28069D45921802D7,DS18B20,30.1,1
2021.02.14 09:41:26 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:27 4: usbmaster, SimpleWrite: $2
2021.02.14 09:41:27 5: usbmaster, read_OW : 2
2021.02.14 09:41:27 5: usbmaster, ReadFn RAW: $2;o;00;02;55;0 / buf :$2;o;00;02;55;0
2021.02.14 09:41:27 5: usbmaster, ReadFn RAW: $2;o;00;02;55;0
2021.02.14 09:41:27 5: usbmaster, ReadFn RAW: $2;o;00;02;55;05;7F;7E;81;66;17;57;
/ buf :5;7F;7E;81;66;17;57;
2021.02.14 09:41:27 4: usbmaster, read[1] : 2;o;00;02;55;05;7F;7E;81;66;17;57;
2021.02.14 09:41:27 5: usbmaster: dispatch OW,2846794592180267,DS18B20,32.0,2
2021.02.14 09:41:27 5: ParseFn, OW,2846794592180267,DS18B20,32.0,2
2021.02.14 09:41:27 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:27 4: usbmaster, SimpleWrite: $3
2021.02.14 09:41:27 5: usbmaster, read_OW : 3
2021.02.14 09:41:27 5: usbmaster, ReadFn RAW: $3;o;DD; / buf :$3;o;DD;
2021.02.14 09:41:27 5: usbmaster, ReadFn RAW: $3;o;DD;
2021.02.14 09:41:27 5: usbmaster, ReadFn RAW: $3;o;DD;01;55;05;7F;7E;81;66;A3;BF;
/ buf :01;55;05;7F;7E;81;66;A3;BF;
2021.02.14 09:41:27 4: usbmaster, read[1] : 3;o;DD;01;55;05;7F;7E;81;66;A3;BF;
2021.02.14 09:41:27 5: usbmaster: dispatch OW,2803DC4592150291,DS18B20,29.8,3
2021.02.14 09:41:27 5: ParseFn, OW,2803DC4592150291,DS18B20,29.8,3
2021.02.14 09:41:27 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:35 5: usbmaster, GetUpdate
2021.02.14 09:41:35 4: usbmaster, SimpleWrite: $?
2021.02.14 09:41:35 5: usbmaster, ReadFn RAW: $0;o;2832AD / buf :$0;o;2832AD
2021.02.14 09:41:35 5: usbmaster, ReadFn RAW: $0;o;2832AD
2021.02.14 09:41:35 5: usbmaster, ReadFn RAW: $0;o;2832AD4592100214;
$1;o;28069D45921 / buf :4592100214;
$1;o;28069D45921
2021.02.14 09:41:35 4: usbmaster, read[1] : 0;o;2832AD4592100214;
2021.02.14 09:41:35 4: usbmaster, found name Stubenfussbodenlinksp for device [0] 2832AD4592100214
2021.02.14 09:41:35 5: usbmaster, ReadFn RAW: $1;o;28069D45921
2021.02.14 09:41:35 5: usbmaster, ReadFn RAW: $1;o;28069D45921802D7;
$2;o;2846794592180267;
$ / buf :802D7;
$2;o;2846794592180267;
$
2021.02.14 09:41:35 4: usbmaster, read[1] : 1;o;28069D45921802D7;
2021.02.14 09:41:35 4: usbmaster, found name Stubenfussbodenrechtsp for device [1] 28069D45921802D7
2021.02.14 09:41:35 4: usbmaster, read[2] : 2;o;2846794592180267;
2021.02.14 09:41:35 4: usbmaster, found name Stubenfussbodenrechts for device [2] 2846794592180267
2021.02.14 09:41:35 5: usbmaster, ReadFn RAW: $
2021.02.14 09:41:35 5: usbmaster, ReadFn RAW: $3;o;2803DC4592150291;
$4;o;019AD / buf :3;o;2803DC4592150291;
$4;o;019AD
2021.02.14 09:41:35 4: usbmaster, read[1] : 3;o;2803DC4592150291;
2021.02.14 09:41:35 4: usbmaster, found name Stubenfussbodenlinks for device [3] 2803DC4592150291
2021.02.14 09:41:35 5: usbmaster, ReadFn RAW: $4;o;019AD
2021.02.14 09:41:35 5: usbmaster, ReadFn RAW: $4;o;019AD4380B000097;
$5;o;0196553A0B00 / buf :4380B000097;
$5;o;0196553A0B00
2021.02.14 09:41:35 4: usbmaster, read[1] : 4;o;019AD4380B000097;
2021.02.14 09:41:35 4: usbmaster, found name Testlinks for device [4] 019AD4380B000097
2021.02.14 09:41:35 5: usbmaster, ReadFn RAW: $5;o;0196553A0B00
2021.02.14 09:41:35 5: usbmaster, ReadFn RAW: $5;o;0196553A0B0000EB;
$S0;73;0
/ buf :00EB;
$S0;73;0
2021.02.14 09:41:35 4: usbmaster, read[1] : 5;o;0196553A0B0000EB;
2021.02.14 09:41:35 4: usbmaster, found name Rauchalarm for device [5] 0196553A0B0000EB
2021.02.14 09:41:35 4: usbmaster, read[2] : S0;73;0
2021.02.14 09:41:35 5: usbmaster, UpdateReadings data : S0 73 0
2021.02.14 09:41:35 5: usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:41:35 5: ParseFn, OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:41:35 5: usbmaster: dispatch OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:41:35 5: ParseFn, OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:41:35 5: usbmaster: dispatch OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:41:35 5: ParseFn, OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:41:35 5: usbmaster: dispatch OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:41:35 5: ParseFn, OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:41:35 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:36 4: usbmaster, SimpleWrite: $0
2021.02.14 09:41:36 5: usbmaster, read_OW : 0
2021.02.14 09:41:36 5: usbmaster, ReadFn RAW: $0;o / buf :$0;o
2021.02.14 09:41:36 5: usbmaster, ReadFn RAW: $0;o
2021.02.14 09:41:36 5: usbmaster, ReadFn RAW: $0;o;EB;01;55;05;7F;7E;81;66;CC;F6;
/ buf :;EB;01;55;05;7F;7E;81;66;CC;F6;
2021.02.14 09:41:36 4: usbmaster, read[1] : 0;o;EB;01;55;05;7F;7E;81;66;CC;F6;
2021.02.14 09:41:36 5: usbmaster: dispatch OW,2832AD4592100214,DS18B20,30.7,0
2021.02.14 09:41:36 5: ParseFn, OW,2832AD4592100214,DS18B20,30.7,0
2021.02.14 09:41:36 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:36 4: usbmaster, SimpleWrite: $1
2021.02.14 09:41:36 5: usbmaster, read_OW : 1
2021.02.14 09:41:36 5: usbmaster, ReadFn RAW: $1;o;E2;01;55;05;7F;7E;81;66;A5; / buf :$1;o;E2;01;55;05;7F;7E;81;66;A5;
2021.02.14 09:41:36 5: usbmaster, ReadFn RAW: $1;o;E2;01;55;05;7F;7E;81;66;A5;
2021.02.14 09:41:36 5: usbmaster, ReadFn RAW: $1;o;E2;01;55;05;7F;7E;81;66;A5;C6;
/ buf :C6;
2021.02.14 09:41:36 4: usbmaster, read[1] : 1;o;E2;01;55;05;7F;7E;81;66;A5;C6;
2021.02.14 09:41:36 5: usbmaster: dispatch OW,28069D45921802D7,DS18B20,30.1,1
2021.02.14 09:41:36 5: ParseFn, OW,28069D45921802D7,DS18B20,30.1,1
2021.02.14 09:41:36 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:37 4: usbmaster, SimpleWrite: $2
2021.02.14 09:41:37 5: usbmaster, read_OW : 2
2021.02.14 09:41:37 5: usbmaster, ReadFn RAW: $2;o;00;02;55;0 / buf :$2;o;00;02;55;0
2021.02.14 09:41:37 5: usbmaster, ReadFn RAW: $2;o;00;02;55;0
2021.02.14 09:41:37 5: usbmaster, ReadFn RAW: $2;o;00;02;55;05;7F;7E;81;66;17;57;
/ buf :5;7F;7E;81;66;17;57;
2021.02.14 09:41:37 4: usbmaster, read[1] : 2;o;00;02;55;05;7F;7E;81;66;17;57;
2021.02.14 09:41:37 5: usbmaster: dispatch OW,2846794592180267,DS18B20,32.0,2
2021.02.14 09:41:37 5: ParseFn, OW,2846794592180267,DS18B20,32.0,2
2021.02.14 09:41:37 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:37 4: usbmaster, SimpleWrite: $3
2021.02.14 09:41:37 5: usbmaster, read_OW : 3
2021.02.14 09:41:37 5: usbmaster, ReadFn RAW: $3;o; / buf :$3;o;
2021.02.14 09:41:37 5: usbmaster, ReadFn RAW: $3;o;
2021.02.14 09:41:37 5: usbmaster, ReadFn RAW: $3;o;DA;01;55;05;7F;7E;81;66;73;8C;
/ buf :DA;01;55;05;7F;7E;81;66;73;8C;
2021.02.14 09:41:37 4: usbmaster, read[1] : 3;o;DA;01;55;05;7F;7E;81;66;73;8C;
2021.02.14 09:41:37 5: usbmaster: dispatch OW,2803DC4592150291,DS18B20,29.6,3
2021.02.14 09:41:37 5: ParseFn, OW,2803DC4592150291,DS18B20,29.6,3
2021.02.14 09:41:37 5: usbmaster, ReadFn RAW:
2021.02.14 09:41:45 5: usbmaster, GetUpdate
2021.02.14 09:41:45 4: usbmaster, SimpleWrite: $?
2021.02.14 09:41:45 5: usbmaster, ReadFn RAW: $0;o;2832AD4592100214;
$ / buf :$0;o;2832AD4592100214;
$
2021.02.14 09:41:45 4: usbmaster, read[1] : 0;o;2832AD4592100214;
2021.02.14 09:41:45 4: usbmaster, found name Stubenfussbodenlinksp for device [0] 2832AD4592100214
2021.02.14 09:41:45 5: usbmaster, ReadFn RAW: $
2021.02.14 09:41:45 5: usbmaster, ReadFn RAW: $1;o;28069D45921802D7;
$2;o;2846 / buf :1;o;28069D45921802D7;
$2;o;2846
2021.02.14 09:41:45 4: usbmaster, read[1] : 1;o;28069D45921802D7;
2021.02.14 09:41:45 4: usbmaster, found name Stubenfussbodenrechtsp for device [1] 28069D45921802D7
2021.02.14 09:41:45 5: usbmaster, ReadFn RAW: $2;o;2846
2021.02.14 09:41:45 5: usbmaster, ReadFn RAW: $2;o;2846794592180267;
$3;o;2803DC45921 / buf :794592180267;
$3;o;2803DC45921
2021.02.14 09:41:45 4: usbmaster, read[1] : 2;o;2846794592180267;
2021.02.14 09:41:45 4: usbmaster, found name Stubenfussbodenrechts for device [2] 2846794592180267
2021.02.14 09:41:45 5: usbmaster, ReadFn RAW: $3;o;2803DC45921
2021.02.14 09:41:45 5: usbmaster, ReadFn RAW: $3;o;2803DC4592150291;
$4;o;019AD4380B000097; / buf :50291;
$4;o;019AD4380B000097;
2021.02.14 09:41:45 4: usbmaster, read[1] : 3;o;2803DC4592150291;
2021.02.14 09:41:45 4: usbmaster, found name Stubenfussbodenlinks for device [3] 2803DC4592150291
2021.02.14 09:41:45 5: usbmaster, ReadFn RAW: $4;o;019AD4380B000097;
2021.02.14 09:41:45 5: usbmaster, ReadFn RAW: $4;o;019AD4380B000097;
$5;o;0196553A0B0000EB;
$S0; / buf :
$5;o;0196553A0B0000EB;
$S0;
2021.02.14 09:41:45 4: usbmaster, read[1] : 4;o;019AD4380B000097;
2021.02.14 09:41:45 4: usbmaster, found name Testlinks for device [4] 019AD4380B000097
2021.02.14 09:41:45 4: usbmaster, read[2] : 5;o;0196553A0B0000EB;
2021.02.14 09:41:45 4: usbmaster, found name Rauchalarm for device [5] 0196553A0B0000EB
2021.02.14 09:41:45 5: usbmaster, ReadFn RAW: $S0;
2021.02.14 09:41:45 5: usbmaster, ReadFn RAW: $S0;73;0
/ buf :73;0
2021.02.14 09:41:45 4: usbmaster, read[1] : S0;73;0
2021.02.14 09:41:45 5: usbmaster, UpdateReadings data : S0 73 0
2021.02.14 09:41:45 5: usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:41:45 5: ParseFn, OW,0196553A0B0000EB,DS2401,present,5,0
2021.02.14 09:41:45 5: usbmaster: dispatch OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:41:45 5: ParseFn, OW,01E5D9370B00005D,DS2401,absent,-1,0
2021.02.14 09:41:45 5: usbmaster: dispatch OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:41:45 5: ParseFn, OW,013AEC370B0000EB,DS2401,absent,-1,0
2021.02.14 09:41:45 5: usbmaster: dispatch OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:41:45 5: ParseFn, OW,019AD4380B000097,DS2401,present,4,0
2021.02.14 09:41:45 5: usbmaster, ReadFn RAW:Wenn man das Print im Log noch evereinheitlicht, erleichtert das ein gefilterten Logbuchauszug. Aktuell sehe ich zumindet 3 Varianten (doppelpunkt, komma und ganz ohne Device):
- 2021.02.14 09:41:45 5: usbmaster, UpdateReadings data : S0 73 0
- 2021.02.14 09:41:45 5: usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,5,0
- 2021.02.14 09:41:45 5: ParseFn, OW,0196553A0B0000EB,DS2401,present,5,0
Oder gibt es dazu eine Filtermöglichkeit, die ich nur noch nicht kenne?
Grüße
THX, Thema Logging : In allen meinen Modulen erfolgt die Ausgabe nach dem Schema Devicename Komma Blank Meldung
-> usbmaster, UpdateReadings data : S0 73 0
Andere Autoren machen es halt anders -> usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,5,0 kommt von Dispatch in fhem.pl
ParseFn, OW,0196553A0B0000EB,DS2401,present,5,0 -> kommt zwar auch von mir, da es aber an dieser Stelle noch keinen Devicenamen gibt tritt an dessen Stelle der Name der Funktion.
00_OW2S0SMSGUARD.pm:v2.0.0-s23734/2021-02-13
erkennt nun wieder meine Temperatursensoren. Vielen Dank, alles unauffällig.
Folgender Versuch: Teilnehmer "Rauchstatus" hinzugenommen und wieder weg.
Der Übergang via "timeout" (presence -> timeout -> absent) scheint zuverlässig:
2021-02-15 12:34:35 Rauchalarm presence: present presence present
2021-02-15 12:34:25 Rauchalarm presence: timeout presence timeout
2021-02-15 12:33:45 Rauchstatus presence: absent presence absent
2021-02-15 12:33:45 Rauchstatus busid: -1 busid -1
2021-02-15 12:33:35 Rauchstatus presence: timeout presence timeout
2021-02-15 12:33:35 Rauchalarm busid: 5 busid 5
2021-02-15 12:33:25 Testlinks presence: present presence present
2021-02-15 12:33:25 Rauchstatus busid: 5 busid 5
2021-02-15 12:33:25 Rauchalarm busid: 6 busid 6
2021-02-15 12:33:14 Testlinks presence: timeout presence timeout
2021-02-15 12:33:14 Rauchstatus presence: present presence present
2021-02-15 12:33:14 Rauchstatus busid: 2 busid 2
2021-02-15 12:33:14 Rauchalarm busid: 3 busid 3
Das hinzukommen von Teilnehmern induziert unter Umständen ein "timeout" bei bestehenden Busteilnehmern.
Das wegbleiben von Teilnehmern hingegen nicht (Beispiel Rauchalarm ist zeitlich zu weit weg, die ersten beiden Zeilen umhin unabhängig vom Versuch).
Ein "Alarmierung" bei "absent" also sehr zuverlässig (aus meiner Sicht robust und über das Attribut timeout sogar einstellbar zu Lasten der Reaktionsgeschwindigkeit)
Was meint das (neue?) Internal ".attreocr-thresholdtemperature"?
Zitat von: Jostar am 15 Februar 2021, 13:30:23
Was meint das (neue?) Internal ".attreocr-thresholdtemperature"?
Liegt nicht in meiner Verantwortung -> grep attreocr fhem.pl
Du selbst hast irgendwas ins Attribut event-on-change-reading geschrieben und die ganze Zeit als du die "versteckten" Internals und Readngs ausgeblendet hattest ist dir sowas halt nie aufgefallen.
Heute mal ein Update in eigener Sache : ich will demnächst das Ding wieder in den aktiven Dienst versetzen und dazu benötige ich für die S0 Zähler Werte über bestimmte Zeiträume und muss Vorsorge treffen wenn die Counter sich mal ohne meinen willen nullen.
Neues Attribut A_offset bzw b_offset , Fixwert der zum aktuellen Zähler immer addiert wird.
Neues Attribut : A_calc bzw B_calc , berechnet Werte für letzte Minute, Stunde, Tag, Woche Monat und Jahr.
I.d.R. wird sowas immer rückwirkend berechnet (after) , das hat IMHO allerdings den Nachteil das für wechselnde Logfiles der Abschluss des Zeitraums im entsprechenden Logfile fehlt und quasi als der Startwert im neuen Log landet. Ich finde das jedesmal ärgerlich beim anlegen von SVGs.
Die andere Methode ist (before) im aktuellen Durchlauf zu schauen wann laut Intervall der nächste Durchlauf fällig wäre und ob dieser dann auch eine neue Periode wäre.
In so einem Fall wird der aktuelle Zeitraum sofort abgeschlossen d.h. der Endwert landet noch im aktuellen Logfile.
Allerdings hat diese Methode auch einen möglichen Nachteil, wenn es ganz blöd läuft kann auch mal ein Wert fehlen.
(Ist mir bei meinen Stromverbrauch Berechnung mit einem anderen Modul in zwei Jahren erst einmal passiert)
Bsp : aktuell 23:59:49 , Intervall 10 Sekunden, Tag wird noch nicht abgeschlossen da heute noch ein Durchlauf um 23:59:59 erfolgen müsste.
Wenn dieser nun nicht wie geplant um 23:59:59 statt findet sondern verspätet erst um 0:00:00 wird der Tag nicht abgeschlossen.
Wer es gar nicht mag kann es jederzeit mit never ganz abschalten.
Hallo, das klingt ja spannend.
Wie verhinderst du ein Auswirken einer "Zählernullung"? Ich hatte ein userreading mit monoton-Funktion. Aber es ist mir noch nicht vorgekommen, dass es sich "nullt".
Die Problematik der korrekten Summen hat mich auch schon gestört (insbesondere die grafische Darstellung)
Die Statistikwerte berechne ich mit dem statistics Modul nach dem Schema:
singularReadings Stromzaehler:total:Delta:(Year|Month|Hour|Day)
Der Eintrag erfolgt immer 5 Sekunden "vor um", wenn ich das richtig gesehen habe. Passt für meine Anwendung. Was ist das Problem, wenn die letzten 5 Sekunde von gestern in die Summe von heute fließen?
Ich habe aber auch schon "händisch" an anderen Stellen Summen erzeugt und dann einfach mit einem anderen Zeitstempel in der Datenbank versehen, dann passt die Zuordnung in Graphen und die Werte sind auch korrekt.
Zitat von: Jostar am 16 Februar 2021, 00:40:15
Wie verhinderst du ein Auswirken einer "Zählernullung"?
Gar nicht, die SNulls sind Honecker Zähler (vorwärts immer , rückwärts nimmer) und ausser Null Befehl gibt es kein Set Befehl.
Daher wie u.a. beim Revolt Modul : wenn der aktuelle Stand nicht passt : fixer Offset dazu (plus oder minus)
ZitatDie Statistikwerte berechne ich mit dem statistics Modul
sicher kann jeder machen wie er möchte, ich vermeide statistics wenn möglich
ZitatWas ist das Problem, wenn die letzten 5 Sekunde von gestern in die Summe von heute fließen?
die Darstellung in SVGs
ZitatIch habe aber auch schon "händisch" an anderen Stellen Summen erzeugt
klar kann man machen, überfordert aber viele User
@Jostar
Moin Jostar,
da ich meinen SMSGUARD Busmaster auch mit einem Gaszähler und vier Temperaturfühlern in Betrieb nehmen möchte, wäre ich dir dankbar, wenn du deinen Hardware-Aufbau hier beschreiben könntest.
Bin nämlich ein ziemlicher Elektronik-NOOB und möchte nix verbrutzeln.
Vielen Dank im Voraus
Det :)
Hallo, viel gibt es nicht zu beschreiben. Der Master hängt an einem 3 m langen USB-Kabel am Raspberry. An den beiden Kontakten für den Bus sind die 6 Sensoren parallel aufgeklemmt. Der S0-Zähler hat separaten Anschluss.
Viele Grüße und frohes Gelingen!
Guten Abend,
das Modul hat nun ein Jahr lang sehr zuverlässig funktionier. Leider habe ich ein aktuelles Problem, was auch schon seit Wochen besteht und wohl durch ein Update ausgelöst wurde.
Meine Sub-Geräte werden nicht mehr aktualisiert.
Internals:
.AttrList interval disable:0,1 DS2401_Timeout A_offset A_calc_mode:after,before,never A_calc_current:0,1 B_calc_mode:after,before,never B_calc_current:0,1 B_offset mapOWIDs useSubDevices:0,1 delay:0.01,0.05,0.1,0.5,1 model:master,unknown,DS2401,DS1820,DS18B20,DS1822 event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading
.FhemMetaInternals 1
DEF /dev/ttyUSB0@38400
DELAY 0.5
DeviceName /dev/ttyUSB0@38400
FD 41
FUUID 6021337d-f33f-bea7-06c1-e21380fa4e1bd300
FVERSION 00_OW2S0SMSGUARD.pm:v2.0.0-s23771/2021-02-19
INTERVAL 30
NAME usbmaster
NOTIFYDEV global
NR 88
NTFY_ORDER 50-usbmaster
OW-Dev0 20118C4592050290 => 0
OW-Dev1 2832AD4592100214 => 1
OW-Dev2 2466696CD6281225 => 0
OW-Dev3 019AD4380B000097 => 1
OW-Dev4 0196553A0B0000EB => 1
OW-Dev5 2906994D12988293 => 0
OWDEVICES 6
OWVals 2414
PARTIAL
STATE A: 15000 - B: 0
SVN 23771
TIMEOUT 0.5
TYPE OW2S0SMSGUARD
addr master
.attraggr:
.attreocr:
.*
.attrminint:
.attrtocr:
.*
.clientArray:
.userReadings:
HASH(0x358daa8)
Helper:
DBLOG:
statTotalHourLast:
logdb:
TIME 1645887595.07189
VALUE 0.00
statTotalLast:
logdb:
TIME 1645887595.07189
VALUE Hour: 0.00 Day: 0.04 Month: 4.79 Year: 40.72
state:
logdb:
TIME 1645901810.89718
VALUE A: 15000 - B: 0
total:
logdb:
TIME 1645829734.046
VALUE 5800
OLDREADINGS:
READINGS:
2022-02-26 19:57:31 .ds2401 0196553A0B0000EB,019AD4380B000097
2022-02-25 23:55:34 A 15000
2020-05-15 22:13:12 Abase 5650
2021-12-29 11:19:11 B 0
2022-02-25 23:54:12 Stubenfussbodenlinks 25.6
2022-02-26 19:42:18 Stubenfussbodenlinksp 27.9
2022-02-25 23:54:11 Stubenfussbodenrechts 27.2
2022-02-25 23:54:11 Stubenfussbodenrechtsp 25.5
2022-02-26 19:56:50 Testlinks present
2022-02-26 19:56:50 Testrechts present
2022-02-26 19:57:31 error got NOK for OW device 5 [2906994D12988293]
2022-02-26 19:20:15 statTotal Hour: 0 Day: 0 Month: 0 Year: 0 (since: 2022-02-26_19:20:15 )
2022-02-26 19:20:15 statTotalDay 0
2022-02-24 23:59:55 statTotalDayLast 0.04
2022-02-26 19:20:15 statTotalHour 0
2022-02-26 15:59:55 statTotalHourLast 0.00
2022-02-26 15:59:55 statTotalLast Hour: 0.00 Day: 0.04 Month: 4.79 Year: 40.72
2022-02-26 19:20:15 statTotalMonth 0
2022-01-31 23:59:55 statTotalMonthLast 4.79
2022-02-26 19:20:15 statTotalYear 0
2021-12-31 23:59:55 statTotalYearLast 40.72
2022-02-26 19:56:50 state A: 15000 - B: 0
2022-02-25 23:55:34 total 5800
helper:
_98_statistics Statistik_PWP
OW:
0:
addr 20118C4592050290
state 0
time 2022-02-26 19:57:30
1:
addr 2832AD4592100214
fam 28
name Stubenfussbodenlinksp
raw BE 01 55 05 7F 7E 81 66 87 132
state 1
time 2022-02-26 19:57:31
typ DS18B20
value 27.9
100:
0196553A0B0000EB:
busid 4
name Testrechts
presence present
time 2022-02-26 19:57:31
019AD4380B000097:
busid 3
name Testlinks
presence present
time 2022-02-26 19:57:31
2:
addr 2466696CD6281225
state 0
time 2022-02-26 19:57:31
3:
addr 019AD4380B000097
fam 1
name Testlinks
state 1
time 2022-02-26 19:57:31
typ DS2401
4:
addr 0196553A0B0000EB
fam 1
name Testrechts
state 1
time 2022-02-26 19:57:31
typ DS2401
5:
addr 2906994D12988293
state 0
time 2022-02-26 19:57:31
Attributes:
comment 0196553A0B0000EB=Testrechts, 019AD4380B000097=Testlinks, 013AEC370B0000EB=Rauchstatus, 0196553A0B0000EB=Rauchalarm, 2803DC4592150291=Stubenfussbodenlinks, 28069D45921802D7=Stubenfussbodenrechtsp, 2846794592180267=Stubenfussbodenrechts, 2832AD4592100214=Stubenfussbodenlinksp
.*(Day|Hour|Month|Year)Last
event-on-change-reading .*
interval 30
mapOWIDs 0196553A0B0000EB=Testrechts, 019AD4380B000097=Testlinks, 013AEC370B0000EB=Rauchstatus, 0196553A0B0000EB=Rauchalarm, 2803DC4592150291=Stubenfussbodenlinks, 28069D45921802D7=Stubenfussbodenrechtsp, 2846794592180267=Stubenfussbodenrechts, 2832AD4592100214=Stubenfussbodenlinksp
model master
room Keller
timestamp-on-change-reading .*
useSubDevices 1
userReadings total { ReadingsNum($NAME,"Abase",0)+ReadingsNum($NAME,"A",1)/100 }
verbose 5
Das Log zeigt Fehler analog dem Reading "error got NOK for OW device 5 [2906994D12988293] 2022-02-26 19:59:31":
2022.02.26 19:58:00 5: usbmaster, GetUpdate
2022.02.26 19:58:00 4: usbmaster, SimpleWrite: $?
2022.02.26 19:58:00 5: usbmaster, ReadFn RAW: $0;n;20 / buf :$0;n;20
2022.02.26 19:58:00 5: usbmaster, ReadFn RAW: $0;n;20
2022.02.26 19:58:01 5: usbmaster, ReadFn RAW: $0;n;20118C4592050290;
$1;o;2832AD459 / buf :118C4592050290;
$1;o;2832AD459
2022.02.26 19:58:01 4: usbmaster, read[1] : 0;n;20118C4592050290;
2022.02.26 19:58:01 3: usbmaster, got NOK for OW device 0 [20118C4592050290]
2022.02.26 19:58:01 5: usbmaster, ReadFn RAW: $1;o;2832AD459
2022.02.26 19:58:01 5: usbmaster, ReadFn RAW: $1;o;2832AD4592100214;
$2;n;2466696CD6281225; / buf :2100214;
$2;n;2466696CD6281225;
2022.02.26 19:58:01 4: usbmaster, read[1] : 1;o;2832AD4592100214;
2022.02.26 19:58:01 3: usbmaster, intervall 30 is very short to read all 2415 OW devices with a delay of 0.5 seconds
2022.02.26 19:58:01 4: usbmaster, found name Stubenfussbodenlinksp for device [1] 2832AD4592100214
2022.02.26 19:58:01 5: usbmaster, ReadFn RAW: $2;n;2466696CD6281225;
2022.02.26 19:58:01 5: usbmaster, ReadFn RAW: $2;n;2466696CD6281225;
$3;o;019AD4380B000097;
$4;o; / buf :
$3;o;019AD4380B000097;
$4;o;
2022.02.26 19:58:01 4: usbmaster, read[1] : 2;n;2466696CD6281225;
2022.02.26 19:58:01 3: usbmaster, got NOK for OW device 2 [2466696CD6281225]
2022.02.26 19:58:01 4: usbmaster, read[2] : 3;o;019AD4380B000097;
2022.02.26 19:58:01 3: usbmaster, intervall 30 is very short to read all 2415 OW devices with a delay of 0.5 seconds
2022.02.26 19:58:01 4: usbmaster, found name Testlinks for device [3] 019AD4380B000097
2022.02.26 19:58:01 5: usbmaster, ReadFn RAW: $4;o;
2022.02.26 19:58:01 5: usbmaster, ReadFn RAW: $4;o;0196553A0B0000EB;
$5;n;2906994D12988293;
$S0;15000;0
/ buf :0196553A0B0000EB;
$5;n;2906994D12988293;
$S0;15000;0
2022.02.26 19:58:01 4: usbmaster, read[1] : 4;o;0196553A0B0000EB;
2022.02.26 19:58:01 3: usbmaster, intervall 30 is very short to read all 2415 OW devices with a delay of 0.5 seconds
2022.02.26 19:58:01 4: usbmaster, found name Testrechts for device [4] 0196553A0B0000EB
2022.02.26 19:58:01 4: usbmaster, read[2] : 5;n;2906994D12988293;
2022.02.26 19:58:01 3: usbmaster, got NOK for OW device 5 [2906994D12988293]
2022.02.26 19:58:01 4: usbmaster, read[3] : S0;15000;0
2022.02.26 19:58:01 5: usbmaster, UpdateReadings data : S0 15000 0
2022.02.26 19:58:01 5: usbmaster, calcS0 A never
2022.02.26 19:58:01 5: usbmaster, calcS0 B never
2022.02.26 19:58:01 5: usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,4,0
2022.02.26 19:58:01 3: usbmaster: Unknown code OW,0196553A0B0000EB,DS2401,present,4,0, help me!
2022.02.26 19:58:01 5: usbmaster: dispatch OW,019AD4380B000097,DS2401,present,3,0
2022.02.26 19:58:01 3: usbmaster: Unknown code OW,019AD4380B000097,DS2401,present,3,0, help me!
2022.02.26 19:58:01 5: usbmaster, ReadFn RAW:
2022.02.26 19:58:02 4: usbmaster, SimpleWrite: $1
2022.02.26 19:58:02 5: usbmaster, read_OW : 1
2022.02.26 19:58:02 5: usbmaster, ReadFn RAW: $1;o;BE;01;55;05;7F;7E;81;66; / buf :$1;o;BE;01;55;05;7F;7E;81;66;
2022.02.26 19:58:02 5: usbmaster, ReadFn RAW: $1;o;BE;01;55;05;7F;7E;81;66;
2022.02.26 19:58:02 5: usbmaster, ReadFn RAW: $1;o;BE;01;55;05;7F;7E;81;66;87;84;
/ buf :87;84;
Kann das an einem Update liegen? Die letzten Werte wurden regulär am 2.2. erfasst. Das kann gut sein, dass ich da ein Update gemacht habe, die Version vom Modul ist:
00_OW2S0SMSGUARD.pm 23771 2021-02-19 06:02:21Z Wzut
Die Datei sagt allerdings was anderes:
Zugriff : 2019-08-05 23:04:51.728474000 +0200
Modifiziert: 2021-12-29 11:22:12.120414639 +0100
Geändert : 2021-12-29 11:22:12.120414639 +0100
Hat sich etwas gundlegendes geändert?
Beste Grüße
Guten Abend,
Also, an dem Modul (00_OW2S0SMSGUARD.pm) kann es nicht liegen, dass hat sich nicht geändert. Auch scheinen nach wie vor plausible Werte empfangen zu werden (siehe log oben) nur der Dispatch sagt "unbekannter Code". In die Funktion habe ich mal reingeschaut, da hat sich tatsächlich was geändert (siehe Anhang).
Aufgerufen wird der Dispatcher hier im Modul, nur was genau klemmt denn da nun?
my $model = $hash->{helper}{OW}{$num}{typ};
$hash->{helper}{OW}{$num}{raw} = join(' ' , @data);
my $temp;
if ($model ne 'unknown') {
$temp = decodeTemperature($model, @data);
return ErrorLog($hash,"unable to decode data $hash->{helper}{OW}{$num}{raw} for model $model") if ($temp eq '');
}
$temp //= $hash->{helper}{OW}{$num}{raw};
$hash->{helper}{OW}{$num}{value} = $temp;
if (!AttrNum($name, 'useSubDevices', 0)) {
readingsSingleUpdate($hash, $hash->{helper}{OW}{$num}{name}, $temp, 1);
return;
}
readingsSingleUpdate($hash, $hash->{helper}{OW}{$num}{name}, $temp, 0);
Dispatch($hash, "OW,$hash->{helper}{OW}{$num}{addr},$model,$temp,$num");
return;
Danke und Grüße!
tja da müsste man eigentlich jemand fragen das Ahnung von Dispatch hat bzw. sich damit auskennt.
Keine Ahnung ob Rudi da irgend wann was an der Dispatch geändert hat, ich sehe das im Moment so das ja Match oder Matchlist wohl nicht greift.
Bsp
Zitat2022.02.26 19:58:01 5: usbmaster: dispatch OW,0196553A0B0000EB,DS2401,present,4,0
2022.02.26 19:58:01 3: usbmaster: Unknown code OW,0196553A0B0000EB,DS2401,present,4,0, help me!
heute :
$hash->{Clients} = ':OW2S0SMSGUARD:';
$hash->{MatchList} = { '1:OW2S0SMSGUARD' => '^OW.*' };vllt
$hash->{MatchList} = { '1:OW2S0SMSGUARD' => '^OW'};bzw zusätzlich noch
$hash->{Match} = "^OW";
Guten Abend,
vielen Dank für die Code. Habe ich eingefügt. Einzeln und zusammen (Matchlist und Match), aber kann keiner Änderungen der Ergebnisse beobachten. Die Werte kommen nach wie vor in die Readings im Master, aber nicht mehr in die Slaves. Das log zeigt den gleichen Fehler bei Dispatch:
2022.03.08 22:32:47 5: usbmaster, GetUpdate
2022.03.08 22:32:47 4: usbmaster, SimpleWrite: $?
2022.03.08 22:32:47 5: usbmaster, ReadFn RAW: $0;o;2832AD4592100214;
$1;o; / buf :$0;o;2832AD4592100214;
$1;o;
2022.03.08 22:32:47 4: usbmaster, read[1] : 0;o;2832AD4592100214;
2022.03.08 22:32:47 4: usbmaster, found name Stubenfussbodenlinksp for device [0] 2832AD4592100214
2022.03.08 22:32:47 5: usbmaster, ReadFn RAW: $1;o;
2022.03.08 22:32:47 5: usbmaster, ReadFn RAW: $1;o;28069D45921802D7;
$2;o;2846794 / buf :28069D45921802D7;
$2;o;2846794
2022.03.08 22:32:47 4: usbmaster, read[1] : 1;o;28069D45921802D7;
2022.03.08 22:32:47 4: usbmaster, found name Stubenfussbodenrechtsp for device [1] 28069D45921802D7
2022.03.08 22:32:47 5: usbmaster, ReadFn RAW: $2;o;2846794
2022.03.08 22:32:47 5: usbmaster, ReadFn RAW: $2;o;2846794592180267;
$3;o;2803DC459215 / buf :592180267;
$3;o;2803DC459215
2022.03.08 22:32:47 4: usbmaster, read[1] : 2;o;2846794592180267;
2022.03.08 22:32:47 4: usbmaster, found name Stubenfussbodenrechts for device [2] 2846794592180267
2022.03.08 22:32:47 5: usbmaster, ReadFn RAW: $3;o;2803DC459215
2022.03.08 22:32:47 5: usbmaster, ReadFn RAW: $3;o;2803DC4592150291;
$4;o;0196553A0B0000EB;
/ buf :0291;
$4;o;0196553A0B0000EB;
2022.03.08 22:32:47 4: usbmaster, read[1] : 3;o;2803DC4592150291;
2022.03.08 22:32:47 4: usbmaster, found name Stubenfussbodenlinks for device [3] 2803DC4592150291
2022.03.08 22:32:47 4: usbmaster, read[2] : 4;o;0196553A0B0000EB;
2022.03.08 22:32:47 4: usbmaster, found name Rauchalarm for device [4] 0196553A0B0000EB
2022.03.08 22:32:47 5: usbmaster, ReadFn RAW:
2022.03.08 22:32:47 5: usbmaster, ReadFn RAW: $S0;15049;7000
/ buf :$S0;15049;7000
2022.03.08 22:32:47 4: usbmaster, read[1] : S0;15049;7000
2022.03.08 22:32:47 5: usbmaster, UpdateReadings data : S0 15049 7000
2022.03.08 22:32:47 5: usbmaster, calcS0 A never
2022.03.08 22:32:47 5: usbmaster, calcS0 B never
2022.03.08 22:32:47 5: usbmaster: dispatch 019AD4380B000097,DS2401,absent,-1,0
2022.03.08 22:32:47 3: usbmaster: Unknown code 019AD4380B000097,DS2401,absent,-1,0, help me!
2022.03.08 22:32:47 5: usbmaster: dispatch 01E5D9370B00005D,DS2401,absent,-1,0
2022.03.08 22:32:47 3: usbmaster: Unknown code 01E5D9370B00005D,DS2401,absent,-1,0, help me!
2022.03.08 22:32:47 5: usbmaster: dispatch 0196553A0B0000EB,DS2401,present,4,0
2022.03.08 22:32:47 3: usbmaster: Unknown code 0196553A0B0000EB,DS2401,present,4,0, help me!
2022.03.08 22:32:48 5: usbmaster, ReadFn RAW:
Noch Ideen, was ich probieren könnte?
Viele Grüße
Anscheinend ist hier der physische und der logische Teil in einem Modul.
Es gibt zwar für den physischen Teil
$hash->{Clients} = ':OW2S0SMSGUARD:';
$hash->{MatchList} = { '1:OW2S0SMSGUARD' => '^OW.*' };
aber für den logischen Teil fehlt
$hash->{Match} =
Grüße
Zitat von: CoolTux am 09 März 2022, 13:06:12
aber für den logischen Teil fehlt
$hash->{Match} =
hatte ich aber in #112 geschrieben -> $hash->{Match} = "^OW";
Zitat von: Wzut am 09 März 2022, 13:39:55
hatte ich aber in #112 geschrieben -> $hash->{Match} = "^OW";
Ich habe eben nur über das aktuelle Modul im SVN geschaut. Dabei ist es mir aufgefallen. Da Du der Author bist könntest Du das vielleicht einfügen und dann noch mal testen.
Ich hatte heute endlich mal Zeit zum testen, das zusätzliche $hash->{Match} = 'OW'; reicht aus damit Parse wieder greift.
Neue Version liegt im svn
Guten Abend, nun ja, was soll ich sagen, es funktioniert wieder, danke!
(entweder war ich zu dumm zum abtippen, oder hatte noch irgendwelche Folgefehler im System, da ich anfangs meine Verkabelung im Verdacht hatte).
Grüße!