Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serial Send #12

Open
3 tasks
bismosa opened this issue Aug 10, 2019 · 4 comments
Open
3 tasks

Serial Send #12

bismosa opened this issue Aug 10, 2019 · 4 comments

Comments

@bismosa
Copy link
Collaborator

bismosa commented Aug 10, 2019

Hallo!

Ich trenne das jetzt von hier: #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.

  • Gültige Eingabe: 0 - 850176
  • Wird das Attribut gesetzt, wird das Attribut "Serial_send" mit dem Hex-Wert "Serial_send_num16 * 16" ausgefüllt.
  • Wird das Attribut "Serial_send" als Hex gesetzt, wird das Attribut "Serial_send_num16" automatisch ausgefüllt (Serial_send / 16).
  • Wird ein Code empfangen, wird ein neues Reading "serial_receive_num16" erzeugt. (serial_receive / 16)
  • Die Doku habe ich auch schonmal versucht anzupassen

Der Patch ist hier zu finden:
bismosa/RFFHEM@34c3b15
(Ich habe keine Ahnung, wie ich das besser übermitteln könnte)

ToDo (?)

  • Bei bestehenden Devices wird das Attribut "Serial_send_num16" nicht automatisch gesetzt
  • Ist der Name "Serial_send_num16" wirklich einleuchtend?
  • Sollte beim setzen der Serial_send eine Gültigkeitsprüfung mit eingebaut werden?

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

Gruß
Bismosa

@HomeAutoUser
Copy link
Collaborator

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
Copy link
Collaborator Author

bismosa commented Aug 30, 2019

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
Copy link
Collaborator

Ich habe mir den Istzustand mal angesehen.

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

  • prüfen auf die Eingabe des Benutzer ob diese Hex ist
  • Länge prüfen
  • Eingabe übernehmen und auf das notwendige Format ggf. zusätzlich ergänzen

ggf zusätzlich

  • Prüfung auf Nummmerisch, wenn ja dann eine Wandlung vornehmen in Hex

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
Copy link
Collaborator Author

bismosa commented Sep 2, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants