-
Notifications
You must be signed in to change notification settings - Fork 33
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
sendMsg hex value - error #782
Comments
Durch irgendwas wird das Ganze beeinflusst. Nach mehrmaligen Shutdown´s kann ich auf einmal dieses Kommando absetzen ohne das der Fehler kommt. Hier ist etwas Wurmbehaftet. |
Was genau ist der Fehler? |
Der Fehler sind die Steuerzeuchen
|
Hmm, könnte das nicht eher ein Fehler auf dem uC sein? Dort wird ausgegeben, was vom uC empfangen wurde. |
Durch aus möglich. Daran dachte ich auch schon. Das einzige was ich weiß, ich habe versucht öfter zu senden. |
Da ich nun den uC mal gestresst habe und den Fehler nicht reproduzieren konnte, würde ich dies "vorsichtig" zu den Akten legen wollen. ABER dabei war mir aufgefallen, ob wir noch einen Fall abfangen können und wollen. Sobald jemand vergisst oder den Befehl falsch zum senden eingibt wie
weil das Richtig wäre Wie seht Ihr das? |
Solange nur eine Warnung kommt, sehe ich das nicht so kritisch. |
Wir könnten eine Syntaxprüfung einbauen. |
Abschießen möchte ja keiner den Signalduino. Wenn es dennoch geht, sollten wir dies unterbinden. Man könnte ja prüfen ob die Eingabe vielleicht richtig ist. |
Kannst du den Fall nachstellen wann dies geschiet? Dies würde ich dann in dem Faden behandeln anderenfalls würde ich das Issues closen sobald wir nicht den Fall nachstellen können. |
Ich habe mir nur den einen Fall gemerkt, wie man den SIGNALduino zuverlässig zum dauernd Senden veranlasst: Dieser Befehl in der Kommandozeile schaltet FS10_2_11 aus:
Nimmt man versehentlich diesen Teil
in der Detailansicht in die Eingabemaske für set raw und setzt den Befehl ab, hat man einen prima Störsender. |
Gerade noch ein Beispiel im Forum entdeckt (https://forum.fhem.de/index.php?topic=107868.msg1019168#msg1019168): Nach dem Senden folgender Nachricht empfängt der SIGNALduino nichts mehr. Die Nachricht ist sicher zu lang. Ein Reset aus FHEM erfolgt nicht.
|
Hier https://forum.fhem.de/index.php/topic,107868.msg1019479.html#msg1019479 kam ein Hinweis von @Ralf9:
Theoretisch könnte eigentlich nur etwas passieren, wenn clockabs und einer der Faktoren in one, zero usw. kein Integer ist. Vieleicht sollten wir es trotzdem ändern. |
Ich denke dem sollte nichts entgegen sprechen und letztendlich stellt es ja auch nur noch eine zusätzliche "Absicherung" dar. |
Ist doch gefixt oder doch nicht? |
Ein Bruchteil ist gefixt aber nicht alles. Das müsste noch offen sein #782 (comment) oder #782 (comment) ... @elektron-bbs siehst du das genau so? |
@elektron-bbs das #782 (comment) ging bestimmt unter. |
Dieses #782 (comment) ist IMHO auch noch nicht erledigt, oder habe ich etwas übersehen? |
Also scheint hier noch bei allem Handlungsbedarf ;) |
Bis auf diesen: #782 (comment) |
Den Teil für sendMsg der den Parameter zerlegt würde ich gerne überarbeiten. |
Ich hänge hier mal noch einen Beitrag eines Users bezüglich "sendmsg" an diese Sammlung an: #906 (comment) |
Expected Behavior
Actual Behavior
cmd
set nano_433Mhz sendMsg P88#0x2C4A49F8808B48058#R1
not right intern work
via FHEM cmd line
via device set
Steps to Reproduce the Problem
Specifications
The text was updated successfully, but these errors were encountered: