Signalduino (u.a.): Vorschlag für bessere Doku, welche Geräte erkannt werden

[Harst]

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

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

[Waldmensch]

Hört sich gut an, aber das Wiki wäre der bessere Platz dafür, oder?


Gesendet von iPhone mit Tapatalk

[Harst]

Hallo,
da würde ich die Doku ja gerne hinstellen, aber die Diskussion ist da schwieriger

Horst

[dora71]

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

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?

[Ralf9]

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

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

[Harst]

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

[Harst]

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.

[HomeAuto_User]

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

[Harst]

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

[HomeAuto_User]

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

[Harst]

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

[HomeAuto_User]

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 . 

[HomeAuto_User]

Ich habe mal bewußt ein Gerät gewählt, das noch unbekannt ist.

Horst

Code Auswählen Erweitern

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


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. 

[Harst]

Hier mach ich weiter:

https://forum.fhem.de/index.php/topic,96951.0.html

Horst