Hallo zusammen,
ich habe ein kleines Problem beim erkennen zweier 1Wire-Devices
mit gleicher ID aber Unterschiedlicher Familien-ID (26- und 28-).
Zur Hardware:
Raspberry mit ConfigurableFirmata_DS2482.ino (2.06)
An fünf Ports des Arduino-Mega können 1-Wire Bausteine angeschlossen werden.
define FIRMATA FRM 3030 global
attr FIRMATA room OWX,System
attr FIRMATA verbose 1
#Port 5 Firmata
define OWio5 OWX 5
attr OWio5 IODev FIRMATA
attr OWio5 room OWX,System
Ich habe von Tobias Müller neue Module mit ATTINY84 bekommen.
Diese können je nach Wunsch, unterschiedliche DS-Bausteine simulieren.
Als Einfachstes Beispiel folgendes:
Das erste Device simulierte ein DS2438 mit der ID
Zitat
26.A3D984001605
Das zweite Device simuliert ein DS18B20 mit der ID
Zitat
28.A3D984001605
Natürlich könnte man die IDs beliebgig festlegen. Aber laut Dallas/Maxim
ist es möglich, wenn auch sehr unwahrscheinlich, dass zwei 1-Wire Devices
mit verschiedenen Family-IDs den gleichen Rest der ID haben.
(Der CRC-Wert ist dann natürlich auch unterschiedlich).
In der CFG habe ich den DS2438 so definiert:
define OWX_26_A3D984001605 OWMULTI 26.A3D984001605
attr OWX_26_A3D984001605 IODev OWio5
Der simulierte DS18B20 ist so definiert:
define OWX_28_A3D984001605 OWTHERM 28.A3D984001605
attr OWX_28_A3D984001605 IODev OWio5
Anhand der IDs sollten keine Probleme auftreten.
Es werden im Betrieb beide Devices angesprochen. Das Auslesen funktioniert ohne Probleme.
Im Logfile werden die zwei Bausteine angemeckert
CFG-Dateien für beide Devices:
Zitat
2015.10.17 18:10:40 1: Including /opt/fhem/FHEM/DS18B20_OWX_28_A3D984001605_00.cfg
2015.10.17 18:10:40 3: OWTHERM: Device OWX_28_A3D984001605 defined.
2015.10.17 18:10:40 1: Including /opt/fhem/FHEM/DS2438_EMU_26_A3D984001605_00.cfg
2015.10.17 18:10:40 3: OWMULTI: Device OWX_26_A3D984001605 defined.
.
.
2015.10.17 18:10:35 1: OWX: Warning, OWX_26_A3D984001605 is defined with improper family id 26, must
enter correct model in configuration
2015.10.17 18:10:35 1: OWX: Warning, OWX_26_A3D984001605 is defined with improper family id 28, must
enter correct model in configuration
2015.10.17 18:10:35 1: OWX: 1-Wire devices found on bus OWio5
(OWX_28_A2D984001677,OWX_26_A3D984001605,OWX_26_A3D984001605)
2015.10.17 18:10:35 1: OWX: 1-Wire devices found on bus OWio6
(OWX_20_A2D984001602,OWX_28_60BFC3040000,OWX_26_ECC2A1010000,OWX_26_1C489E010000,OWX_26_A2D984000006,
OWX_26_A2D984000005,OWX_26_A2D984002602,OWX_1D_A2D984000002)
2015.10.17 18:10:35 1: OWX: 1-Wire devices found on bus OWio7 ()
2015.10.17 18:10:36 1: OWX: 1-Wire devices found on bus OWio2 (OWX_28_736020050000)
2015.10.17 18:10:36 1: OWX: 1-Wire devices found on bus OWio3
(OWX_28_FF313C4E0400,OWX_26_A2D984000007)
2015.10.17 18:10:36 1: OWX: Warning, OWX_26_A3D984001605 is defined with improper family id 26, must
enter correct model in configuration
2015.10.17 18:10:36 1: OWX: Warning, OWX_26_A3D984001605 is defined with improper family id 28, must
enter correct model in configuration
2015.10.17 18:10:36 1: OWX: 1-Wire devices found on bus OWio5
(OWX_28_A2D984001677,OWX_26_A3D984001605,OWX_26_A3D984001605)
Nach dem am Port Owio5 der 28_A3D984001605 erkannt wurde, wird der 26_A3D984001605 gelesen.
Wenn ich nun am Port Owio5 der Firmata die Devices abfrage, werden mir zwei Devices angezeigt aber
mit gleicher ID!
"get OWio5 devices" zeigt nun dies an:
Zitat
OWX: 1-Wire devices found on bus OWio5
28.A3D984001605 DS18B20 OWX_26_A3D984001605
26.A3D984001605 DS2438 OWX_26_A3D984001605
Spreche ich die beiden Devices jeweils getrennt über die Web-Oberfläche an,
kann man darauf zugreifen. Diagramme und Logs werden ohne Probleme geschrieben.
Hat hier zu irgend jemand eine Lösung oder Antwort?
Danke.
Gerd
Hi,
>Hat hier zu irgend jemand eine Lösung oder Antwort?
Nimm eine andere ID. Dich kostet das 5 Minuten
Eigentlich sollte das so gehen, aber wer testet so was schon.
Viele Grüße
R.
Das sollte in der Tat nicht auftreten - ist aber wirklich nicht getestet. Muss ich mir ansehen, kann sein, dass das eine Sache von 30 Minuten ist - die habe ich aber in den nächsten Tagen nicht.
LG
pah
Hallo Pah
Nur kein Stress.
Wenns passt.
Gruss Gerd
Oh, Fhem ist kein Stress - der kommt aus anderen Quellen...
LG
pah
Hallo pah,
eine Vorsichtige Anfrage ;)
Hattest Du schon Zeit nach dem Problemchen zu schauen?
Zitat von: Prof. Dr. Peter Henning am 01 November 2015, 08:16:41
Das sollte in der Tat nicht auftreten - ist aber wirklich nicht getestet. Muss ich mir ansehen, kann sein, dass das eine Sache von 30 Minuten ist - die habe ich aber in den nächsten Tagen nicht.
LG
pah
Gruss
Gerd
Nein.
Bin gerade noch in der Endredaktion eines Buches, muss noch einen EU-Antrag schreiben und muss noch 2 Klausuren korrigieren.
Danach können wir drüber sprechen
LG
pah
Okay
Danke für die Info und viel Erfolg bei deinen Aufgaben.
Gruss
Gerd
Zitat von: Prof. Dr. Peter Henning am 01 November 2015, 08:16:41
Das sollte in der Tat nicht auftreten - ist aber wirklich nicht getestet.
bin grade beim Entwickeln des DS2890-clones auch auf die Fehlermeldung gestoßen und hab mir das mal angesehen. Bei der Bus-discovery (fhem-start oder get <busmaster> devices) ordnet OWX die gefunden IDs den schon definierten Devices zu. Der Fall, dass die ID eines schon definierten Devices sich nur in der Family-id von einem auf dem Bus gefunden Device unterscheidet wird dabei in 00_OWX.pm ab Zeile 763 (https://github.com/ntruchsess/fhem-mirror/blob/dev/fhem/FHEM/00_OWX.pm#L763) explizit behandelt. Das Ergebnis ist, dass - wenn man tatsächlich 2 solche Devices auf dem Bus hat, die Device-definitionen falsch zugeordnet werden können. Die ursprüngliche ROMID im jeweiligen FHEM-device wird dabei überschrieben. Als Nebenwirkung hat man dann die eigenlicht für das jeweils andere Device gedachten Attribute dranhängen, was sagen wir mal 'überraschende' Ergebnisse nach sich ziehen kann ;-)
Die implementierte Logik wäre sinnvoll, wenn sich die Familyid eines schon definierten Devices tatsächlich selbsttätig ändern könnte (Ist meines Erachtens auszuschließen). Wenn die Family-id durch einen Übertragungsfehler falsch gelesen wurde sollte das durch den nicht mehr passenden CRC-Wert erkannt und die ID schon vorher abgelehnt werden. Auf jeden Fall erscheint mir die implementierte Logik wenig sinnvoll, weil sie einen Fall behandelt, der so in der Realität meines Erachtens nicht auftritt (spontanes Ändern der FamID) und systematisch falsche Ergenisse liefern kann (wenn man 2 unterschiedliche Devices mit gleicher ID, aber unterschiedlicher FamID auf dem Bus hat, wobei ich hier nicht ausdrücken will, dass ich es für schlau halte die IDs quasi vorsätzlich so zu vergeben).
Richtige Analyse, falsche Schlussfolgerung.
Alle OW.. Module kennen die Möglichkeit, 1-wire Devices mit einer Modellbezeichnung und der ROM-ID zu definieren (aber OHNE Family ID). Das ist auch ok, weil die Family ID ja nur ein Ersatz für die Modellbezeichnung ist - soll also auch nicht geändert werden.
Ich habe das Problem in der neuesten Alpha-Version von OWX schon gelöst.
LG
pah
Ach ja, nur so als Nachtrag: Das Problem trat überhaupt nur auf, wenn die Devicenamen mit "OW..." beginnen. Hätte derjenige, der dies zuerst gepostet hat, seine Devices ordentlich benannt, wäre das gar nicht erst hochgekommen.
kann ich jetzt nicht nachvollziehen, was an der Schlussfolgerung falsch sein soll. Verglichen wird die ROM_ID und die wird in den jeweiligen Device-Define-subs aus family-id, device-id und crc zusammengesetzt (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/21_OWTHERM.pm#L236), ganz unabhängig davon, ob der Chip-name oder die Family-id im define so drinnen steht.
Der Name wird bei dem Vergleich auch nicht berücksichtig, es werden bei dem Check alle Devices übersprungen, deren TYPE mit OW anfängt (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/00_OWX.pm#L759) und daran kommt man ja durch manuelles Umbenennen der per Autocreate angelegten defines kaum vorbei.
Eben. Und ich habe die Annahme zu Grunde gelegt, dass bei zwei Devices mit Name "OW...." und gleicher Family ID ein Fehler in Definition gemacht worden ist.
LG
pah