Busmaster mit 2x S0-Interface

[Jostar]

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:
   

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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!

[Jostar]

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":

Code Auswählen Erweitern

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?

[Wzut]

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 :

Code Auswählen Erweitern

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)

[Jostar]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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?

[Wzut]

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 :

Code Auswählen Erweitern

$hash->{helper}{$num}{typ} = 'DS1B820' if ($model == 28);
ich musste auch zweimal hinschauen -> DS1B820 und später wird aber richtig auf DS18B20 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.

Warum 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 ?

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

[Jostar]

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

Code Auswählen Erweitern

-     $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:

Code Auswählen Erweitern

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):

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

PERL WARNING: Argument "^Y���4592180267" isn't numeric in int at ./FHEM/00_OW2S0SMSGUARD.pm line 361.
hatte ich vermieden

Code Auswählen Erweitern

  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:

Code Auswählen Erweitern

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

[Wzut]

1. Kann mann die Dev-Ausgaben wieder aktivieren?

Done

2. Kann man die IDs wieder sichtbar machen?

Wo ? die stehen doch als Value bei OW-Dev

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

das 10.Byte ist eine Checksumme für die serielle Übertragung (Byte1-9 aufaddiert) 

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

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

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

[Jostar]

Das klingt seht gut.
Nr. 1 Die Änderung in den Internals

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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?

[Wzut]

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 ?

Code Auswählen Erweitern

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.

[Jostar]

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.

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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):

Code Auswählen Erweitern

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.

[Wzut]

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.

[Jostar]

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:

Code Auswählen Erweitern

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

[Wzut]

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.

[Jostar]

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 

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

Bei 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!

[Wzut]

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]