Hallo,
Aus eigener Erfahrung habe ich immer wieder das Problem, welche Hardware ich besorgen darf. Oft gibt es mehrere Versionen eines Gerätes, oft andere Namen. Mir würde eine offene, umfangreiche Liste vor Geräten, mit Bildern und Zusatzinfos helfen und ich habe mal einen ersten Vorschlag:
http://horstwessel.eu/?Inhalte/Devices (http://horstwessel.eu/?Inhalte/Devices)
Name | Foto | Senden | Frequenz | Beschreibung | Hinweise | Verwendetes Modul | Protokoll | Version | letzte Prüfung | Gateway |
MD-230R | | E | 430 MHz | Wassersensor | meldet sich als MD-2018R | CUL_TCM97001 | 91 + 91.1 | Dev 3.2.2.1 ab 1.1.2019 | 1/2019 | Signalduino ab RC4 |
Was haltet Ihr davon?
Und was sollte noch rein/raus.
Horst
Hört sich gut an, aber das Wiki wäre der bessere Platz dafür, oder?
Gesendet von iPhone mit Tapatalk
Hallo,
da würde ich die Doku ja gerne hinstellen, aber die Diskussion ist da schwieriger
Horst
Hallo Horst,
die Idee ist gut, aber ich würde einfach die vorhandenen Einträge im Wiki ergänzen/aufbohren. Da gibt es doch schon eine Liste, die braucht nur ergänzt zu werden.
https://wiki.fhem.de/wiki/SIGNALduino#Unterst.C3.BCtzte_Ger.C3.A4te (https://wiki.fhem.de/wiki/SIGNALduino#Unterst.C3.BCtzte_Ger.C3.A4te)
Gruß Rainer
PS: Da war der Waldmensch schneller ;)
PPS: Im Wiki könnte man doch an o.g. Stelle auf einen Thread im Forum verweisen, wo dann die Diskussion stattfindet. Dann ist doch jeder zufrieden, oder?
ZitatAus eigener Erfahrung habe ich immer wieder das Problem, welche Hardware ich besorgen darf. Oft gibt es mehrere Versionen eines Gerätes, oft andere Namen. Mir würde eine offene, umfangreiche Liste vor Geräten, mit Bildern und Zusatzinfos helfen
So eine ähnliche Idee hatte ich auch schon, ich weiss aber nicht wie man das umsetzen kann.
Dies ist vor allem für die Sensoren die das CUL_TCM97001 Modul verwenden interessant, da gibt es bei dem timing (clock, sync, one und zero) recht viele Varianten.
Zu den Einträgen Name, ID, Foto, Beschreibung wäre auch noch ein Feld wichtig wo man raw-Nachrichten eintragen kann.
Gut wäre es, wenn wir raw-Nachrichten von verschiedenen Usern hätten.
Eine allgemeine Protokollübersicht gibt es bereits. Die Übersicht in der Anlage kommt demnächst auch in die dev-r33.
Gruß Ralf
Hallo Ralf,
die allgemeine Protokollübersicht hat oft nicht geholfen, weil es so viele fast gleiche gibt. Ich würde jetzt 2 Tabellen machen. Meine erste mit Links aus den Spalte Protokoll (91.1) in Deine Tabelle mit den technischen Details.
Die Raw-Daten könnte man vielleicht direkt in Git ablegen.
Horst
Wie wäre es so?
https://wiki.fhem.de/wiki/Benutzer:Harst
Von der 91 in der ersten Tabelle geht es dann auf einen Anker der 2.
Hallo,
die Idee finde ich Schonmal gut.
Die RAWMSG wäre nur schön wenn diese mit sofort dort wäre. Ich finde es als Entwickler schwierig immer alles zusammen zu tragen. Alles zusammen wäre besser.
Eine Variante könnte ja sein, auf eine 2. Tabelle zu verweisen wo nur Name und RAWMSG drin stehen.
Mfg
Meinen Vorschlag finde ich inzwischen auch schon wieder suboptimal. Ich hatte schon Mal eine Spalte Detail angelegt. Dort könnte der Verweis eingetragen werden.
Und ich würde auch negativ geteste Geräte eintragen.
Horst
Hallo Horst,
kannst du mal eine RAWMSG eintragen dort, das man sieht wie sich das äußert?
Die Nachrichten sind sehr lang auf jedenfall immer!
MfG
Ich hab mal eine Tabelle mit Raw-Daten und eine mit Link gemacht. Aus meiner Sicht könnten wir das auf 2 Seiten teilen:
- Übersicht für Anwender mit den Geräten
- Link zur 2. Seite (Anker in die Zeile der Tabelle)
- 2. Seite mit den Rawdaten und ggf. weiteren Spalten
Ich habe mal bewußt ein Gerät gewählt, das noch unbekannt ist.
Horst
Für die RAW-Nachrichten,
wie wäre es nur mit einer einfachen Tabelle wie im "Editor von Windows." Die Tabelle würde sehr lang werden und bei mehreren signalen wird das unübersichtlich denke ich . ???
Zitat von: Harst am 04 Februar 2019, 21:39:58
Ich habe mal bewußt ein Gerät gewählt, das noch unbekannt ist.
Horst
2019.02.04 22:56:11 4: sduino_dummy: decoded matched MU Protocol id 94 dmsg u94#5FA2C31CC length 36 dispatch(1/4)
2019.02.04 22:56:11 4: SIGNALduino_unknown incomming msg: u94#5FA2C31CC
2019.02.04 22:56:11 4: SIGNALduino_unknown rawData: 5FA2C31CC
2019.02.04 22:56:11 4: SIGNALduino_unknown Protocol: 94
2019.02.04 22:56:11 4: SIGNALduino_unknown converted to bits: 010111111010001011000011000111001100
2019.02.04 22:56:11 1: sduino_dummy: SIGNALduino_unknown UNDEFINED sensor SIGNALduino_unknown_94 detected
2019.02.04 22:56:11 2: autocreate: define SIGNALduino_unknown_94 SIGNALduino_un SIGNALduino_unknown_94
2019.02.04 22:56:11 2: autocreate: define FileLog_SIGNALduino_unknown_94 FileLog ./log/SIGNALduino_unknown_94-%Y-%m.log SIGNALduino_unknown_94
2019.02.04 22:56:11 4: sduino_dummy: decoded matched MU Protocol id 94 dmsg u94#5FA2C31CC length 36 dispatch(2/4)
2019.02.04 22:56:11 4: sduino_dummy Dispatch: u94#5FA2C31CC, Dropped due to short time or equal msg
2019.02.04 22:56:11 4: sduino_dummy: decoded matched MU Protocol id 94 dmsg u94#5FA2C31CC length 36 dispatch(3/4)
2019.02.04 22:56:11 4: sduino_dummy Dispatch: u94#5FA2C31CC, Dropped due to short time or equal msg
2019.02.04 22:56:11 4: sduino_dummy: decoded matched MU Protocol id 94 dmsg u94#5FA2C31CC length 36 dispatch(4/4)
2019.02.04 22:56:11 4: sduino_dummy Dispatch: u94#5FA2C31CC, Dropped due to short time or equal msg ;D :D
Also die Definition habe ich dir schonmal geschaffen.
PS: Wenn mehr Hilfe benötigt wird, gern dann in Github oder hier in einem neuen Faden. 8)
Hier mach ich weiter:
https://forum.fhem.de/index.php/topic,96951.0.html
Horst