search

fhem / SD_Keeloq

FHEM - Module
https://fhem.de/
3 stars 2 forks source link

Serial Send #12

Open bismosa opened 5 years ago

bismosa commented 5 years ago

Hallo!

Ich trenne das jetzt von hier: https://github.com/HomeAutoUser/Jaro/issues/6 mal auf.

Es geht um gültige Serial_send nummern. Soweit ich es bisher festgestellt habe, muss eine gültige Serial in der Dezimalform durch 16 teilbar sein. Dadurch ist die größtmögliche Serial die FFFFF0 -> Dezimal: 13602816 -> Dezimal/16: 850176.

Diese wurde im Test auch problemlos von meinem Empfänger akzeptiert.

Um gültige Seriennummern eingeben zu können, habe ich mal ein kleinen Patch gemacht. Ich habe ein Attribut "Serial_send_num16" hinzugefügt.

Der Patch ist hier zu finden: https://github.com/bismosa/RFFHEM/commit/34c3b15b1e1760f0fd9a75a62df4296f004dac58 (Ich habe keine Ahnung, wie ich das besser übermitteln könnte)

ToDo (?)

Ich denke das so eine Alternative Eingabemöglichkeit einer Serial gegeben wird, womit jeder etwas anfangen kann.

Gruß Bismosa

HomeAutoUser commented 5 years ago

Hallo, ich arbeite ein wenig ein paar Punkte mal ab. ;-)

Was hälst du von der Variante wenn ich einfach gleich das Attribut Serial_send nur prüfe ;-) Somit wäre ein neues "unnötiges" Reading nicht nötig.

bismosa commented 5 years ago

Kaum ist man Mal ein paar Tage nicht da.. :)

Prüfung ist toll. Ich kann mich aber auch an meine Anfangszeit erinnern wo ich mir (ohne mich mit hex-zahlen auszukennen) einen Code überlegen musste...da hatte ich keinen Plan was ich nehmen soll...da finde ich Dezimalzahlen wesentlich einfacher ;)

Gruß Bismosa

HomeAutoUser commented 5 years ago

Ich habe mir den Istzustand mal angesehen.

Eine Erleichterung wäre für den Endbenutzer ohne zusätzliches Attribut:

ggf zusätzlich

Auf diesem Wege würde man um das Attribut drum herumkommen. Ich denke immer so, zusätzliche "unnötige Attribute" verwirren die User letztendlich.

Beim Empfang würde ich nichts machen. Nur wenn der User selbst handelt und das Attribut setzt geht man auch davon aus, das er bewusst handelt. Zu viele Automatisierungen können zu Missverständnissen führen und später schwieriger Nachvollziehbar sein.

Das was man vielleicht machen könnte, das man beim Empfang ein Internal setzt welches die Seriennummer dezimal ausgibt. Das wird nur gesetzt wenn es Empfangen wird und es sich ändern sollte. Somit erzeugen wir keine Events im System und haben die Information.

bismosa commented 5 years ago

Hallo,

ja. Ich gebe Di recht. Es ist vielleicht zu verwirrend mit den zusätzlichen Attributen.

Die Idee mit dem Internal finde ich gut!

Mit fallen da zusätzlich auch noch folgende Wege ein: 1.) Attribute der Serials komplett ändern auf numerisch. Also komplett weg von den Hex-Serials. Wir haben ja mittlerweile die neuen Erkenntnisse...da wäre das noch gut machbar. Vorteil: Keine doppelten Attribute, keine Verwirrung mehr mit den Serials Nachteil: Alle bisherigen Verwendungen müssten (am besten automatisch) von HEX auf Numerisch geändert werden

2.) Eine Umwandlung als Get-Parameter. Also vielleicht: get HexToSerialNumnber get SerialNumberToHex Dann könnte man in die Beschreibung zur Serial-Send auf diese Wege verweisen. Man könnte sich die Serial von der Hex anzeigen lassen und auch eine gültige "generieren" lassen. Vorteil: Wir müssten die Attribute nicht verändern und es werden keine unnötigen Readings erstellt. Nachteil: Man muss es auch logisch beschreiben können, wobei dies vermutlich noch einfacher wäre, als zu beschreiben, welche Hex-Werte gültig sind

Wenn wir die Serials als Internal in Dezimal anzeigen und auch eine Eingabe als Dezimal erlauben, hätten wir das gleiche natürlich auch schon abgedeckt. :)

Also ich tendiere glaube ich zu den Internals (Empfang und Senden) und der Eingabe als Dezimal (die dann automatisch zur Hex gewandelt wird). Das macht vermutlich am wenigsten Stress und ist logischer.

Gruß Bismosa