[GELOEST] Revolt Steckdosen verhalten sich seltsam

[pc1246]

Moin
Ich habe mir letztens drei Revolt Steckdosen gekauft, da ich es unsinnig fand, PCA301 fuer reine Messaufgaben zu nehmen. Ok, die drei PCAs liegen jetzt sinnlos rum, aber da findet sich was!
Nun zum Problem, erst hatte ich Empfangsprobleme, was bei den Dingern wohl normal ist. Also den Empfaenger naeheran die Dosen gebracht, geht manchmal, manchmal nicht. Ok kontinuierlich ist ja nicht so wichtig, hauptsache grobe Richtung. Aber denkste! Sobald ich denen sinnvolle Namen gebe, moegen die mich nicht mehr, und melden sich unter einer anderen Adresse an!
Wobei sich eigentlich, ja ich weiss, aber es ist nicht zu durchschauen, nur die erste "Ziffer" aendert! Jetzt wollte ich die Dinger schon wieder wegbauen, da habe ich mein neues zukuenftiges Produktivsystem in Betrieb genommen. Und so unglaublich es erscheinen mag, die drei sind konstant da. Was aber das verwunderlichst daran ist, is die Tatsache, dass das IO device exakt das Gleiche ist, ein LacrosseGateway.
Nun tut sich bei mie ein wenig die Vermutung auf, dass da eventuell Timingprobleme eine Rolle spielen, denn mein 2er RPI ist schon ein wenig an der Grenze.
Kann jemand etwas dazu sagen, oder hat aehnliche Beobachtungen gemacht?
Danke und Gruss
Christoph

[KölnSolar]

Hi Christoph,
schon interessant. Die negativen Erfahrungen kenn ich  Die positiven leider (noch) nicht. Kürzlich hatte ich eine Diskussion im Marktplatz m. einem Verkäufer v. Revolts, der Stein u. Bein schwor, dass er allerbesten Empfang hat.
Nun zum obigen "noch".  Ich betreibe die Dosen über CUL, nanoCUL, RFXTRX an einem aktiven USB-Hub. Heute musste ich dann feststellen, dass mein seit Jahren laufendes Netzteil f. den Rpi eigentlich zu schmalbrüstig ist. Durch den Hub blieb mir das aber verborgen  Und nun meine Spekulation: Könnte es bei Dir an einer nun verbesserten Stromquelle liegen ?
Grüße Markus

[pc1246]

Moin Markus
Schoener Plan! Da ich die Revolts ueber LCGs empfange, ist das eher unwarscheinlich, da ich das eine nicht mehr nutzen kann (Bauteildefekt, parallel zum Ersteinsatz der Revolts!). Und das andere seit dem Ersteinsatz sein gewohntes zu Hause verlassen musste, und da seit dem unveraendert haengt!
Gruss Christoph

[mumpitzstuff]

Kann ich jetzt nicht bestätigen. Hab 2 davon seit mehr als einem halben Jahr ohne Probleme laufen. Das eine habe ich auch schon mal in eine andere Steckdose ohne Probleme verlagern können. Du redest allerdings nur von Steckdosen, da kann es natürlich sein, dass du was anderes als ich hast.

[pc1246]

Moin
Ich muss meine Aussage revidieren. Die Revolts zeigen auf beiden Systemen das gleiche Verhalten! Es werden staendig neue Dosen angelegt, und dementsprechend auch Logfiles! Problematisch ist, dass ein ignore mir nicht helfen wuerde, da die dann eine Zeit lang wirklich unter dieser anderen Adresse senden! Irgendwann kommt dann eine neue Adresse, und dann senden die da!
Wer hat diese Dinger wirklich kontinuierlich am Laufen? Womit werden Sie empfangen, und welche Einstellungen habt Ihr?
Ich habe den jeweiligen CUL nur auf SlowRF umgestellt, keine weiteren Einstellungen!
Danke und Gruss
Christoph

[KölnSolar]

Hi Christoph,
ich betreibe sie produktiv mit dem RFXTRX. Der scheint das Protokoll "genauer" zu prüfen, so dass es selten zu falschen Signalen(Id's) kommt. Nur leider ist der RFXTRX eine Blackbox, so dass man einen Unterschied in der firmware zum CUL nicht analysieren kann. Hardwaretechnisch funktioniert der RFXTRX auch etwas anders als ein CUL. Wenn ich es richtig in Erinnerung habe, ist der RFXTRX in der Lage gleichzeitig zu senden u. zu empfangen bzw. empfangene Daten werden zwischengespeichert und gehen nicht verloren. Das alles geht vermutlich zu Lasten der Reichweite/Erkennung der Revolts beim RFXTRX.

da die dann eine Zeit lang wirklich unter dieser anderen Adresse senden! Irgendwann kommt dann eine neue Adresse, und dann senden die da!

Na ja, wirklich senden werden die wohl nicht mit einer anderen ID. Lediglich die Erkennung in aculfw/19_Revolt glaubt wohl eine andere Id gefunden zu haben.

Ich glaube, dass es eine Modifikation der 19_Revolt im Forum gibt, so dass der CUL weniger Erkennungsprobleme hat. Ich hab eine Version auf dem Testsystem mit CUL, die ich wohl am 24.9. eingespielt hab. Musst Du mal suchen.... Vielleicht hilfts.... Nur eigentlich ist es das ja schon zu spät. Die Erkennung müsste in der aculfw verbessert werden bzw. analysiert werden, warum die Erkennung so "schlecht" ist. Liegt es an der Differenzierung gegenüber anderen Protokollen ? Schwankender Genauigkeit/Stärke der Sendung der Revolts ? fehlender Wiederholungen ? ...

Leider hab ich noch nie eine detaillierte Beschreibung der eigentlichen Problematik gelesen, als irgendwelche Lösungen in Softwareform, die dann aber doch nicht helfen.  Sicherlich ist die hohe Frequenz(ca. alle 5s) der Aussendung eines Signals ein Nachteil, weil damit ein recht hoher Traffic erzeugt wird. Dadurch ist es schon fast unmöglich die Signale zu analysieren, wenn man mehr als eine Dose im Einsatz hat.

Irgendwann.......
Grüße Markus

[habeIchVergessen]

SIGNALduino kann laut Sourcen revolt.

[mahowi]

SIGNALduino kann laut Sourcen revolt.

Ja, kann er. Meine Revolts laufen über den SIGNALduino.

[KölnSolar]

Und wie gut oder schlecht, sprich Reichweite, Erkennungsrate, mehrfache Id's.......?

Dann würd ich mich glatt mal damit auseinandersetzen meinen nano als S'duino testweise umzuflashen.

[mahowi]

Also ich komme in einer 120m² Altbauwohnung einmal quer durch die Wohnung. Auch die Mehrfach-IDs kommen kaum noch vor, ab und zu hab ich mal nen Eintrag im Log. Aber die 4 Revolts, die ich habe, funken schon einige Monate unter derselben ID. Allerdings habe ich auch die modifizierte 19_Revolt.pm hier aus dem Forum.

[KölnSolar]

Danke. das sind überzeugende Argumente 

[pc1246]

Hallo Markus
Der CUL erkennt die Daten dann wirklich auf der anderen Adresse! Ich bin ja schon wahnsinnig geworden, weil beim Rename irgendwie wohl immer parallel eine neue Adresse kam, zumindest bei dem einen. Aber ich verstehe was Du meinst.

Hat einer von Euch das Messgeraet parallel dazu in Betrieb?

Mist mit den S'DUINO, da haette ich einen auf Wemos Basis, wo aber die SW nicht so ganz fertig ist. Aber dann haenge ich mich da noch mal rein! Einen 433er CUL habe ich nicht!

Aber trotzdem Danke, da komme ich schon mal ein paar Meter weiter!

Gruss Christoph

[mahowi]

Hab jetzt nochmal gesucht. Ich habe die 19_Revolt.pm aus dem Thread Erweiterung: 19_Revolt.pm von mumpitzstuff.

[pc1246]

So
Ich habe jetzt mal gesucht, und trage es hier mal zusammen, so dass man es eventuell einfacher wiederfinden kann.

https://forum.fhem.de/index.php/topic,71840.msg634032.html#msg634032

https://forum.fhem.de/index.php/topic,78534.msg705095.html#msg705095

http://www.sknorrell.de/blog/energiemesssung-mit-revolt-nc-5462/ ganz unten ist ein link zu einer dropbox, kann ich gerade nicht verifizieren

Aber etwas vom 24.09. finde ich nicht!

Gruss Christoph

[mahowi]

Wie gesagt, ich habe die Version von mumpitzstuff:

Code Auswählen Erweitern

pi@raspberrypi:~ $ ls -la /opt/fhem/FHEM/19_Revolt.pm
-rw-r--r-- 1 fhem dialout 5565 Mai 12  2017 /opt/fhem/FHEM/19_Revolt.pm

[mumpitzstuff]

Das Revolt Protokoll hat den Nachteil, dass es nicht vollständig entschlüsselt wurde. Es wurde nur ein Teil der Prüfsumme geknackt, weshalb es immer wieder vorkommen kann, dass eigentlich ungültige Telegramme als gültig erkannt werden (Prüfsumme hat auch nur 8Bit, ist also nicht besonders gut). Dadurch kommt es oft dazu, dass auch falsche IDs der Revolt Dosen erkannt werden und Autocreate ständig neue Devices anlegt. Teilweise werden bei mir auch andere Dinge erkannt und automatisch angelegt (z.B. IT Devices). Die einzige Lösung für mich an dieser Stelle war, Autocreate abzuschalten (disable setzen) und nur wieder zu aktivieren, wenn ich es wirklich für kurze Zeit brauche.
Mit dieser Einschränkung wird man vermutlich leben müssen wenn man Revolt einsetzt. Aber das Problem gibt es auch bei anderen Protokollen immer mal wieder. Vielleicht kannst du auch bei Autocreate oder im CUL Device einen Filter setzen, so dass es nicht mehr zu den Problemen kommt. Für mich war das disable auf das Autocreate an der Stelle die einfachste Lösung.

[pc1246]

Hallo mumpitzstuff
Mein Problem ist ja, dass dann auch keine Daten mehr kommen. Und da ich die eigentlich am Trockner und der Waschmaschine habe um Fertigmeldungen zu generieren ist das recht bloed! Ich schaue nachher mal dEure Versionen an, und ob ich meinen S'DUINO ans Rennen bekomme!
Vlt. spiele ich auch mal ein wenig mit den Frequenzen und so rum.
Gruss Christoph

[mahowi]

Bei mir kommen die Daten immer an. Wenn per autocreate neue Devices angelegt wurden, blieben deren Logs leer.

Ich habe bei mir autocreate nicht komplett abgeschaltet, sondern stattdessen autocreateThreshold auf Revolt:6:120 gesetzt:

Code Auswählen Erweitern

defmod autocreate autocreate
attr autocreate autocreateThreshold Revolt:6:120
attr autocreate devStateIcon disabled:ios-off:on active:ios-on-blue:off
attr autocreate disable 0
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate ignoreTypes CUL_TX.*|CUL_WS.*

[KölnSolar]

es ist doch immer wieder verwunderlich, was es so alles gibt und man nicht kennt 

attr autocreate autocreateThreshold Revolt:6:120

damit nicht alle nachschlagen müssen  Die Einstellung besagt, dass autocreate bei Revolt-events nur dann aktiv wird, wenn nicht innerhalb von 120s mindestens 6 events aufgetreten sind.
Das probier ich dann mal bei Gelegenheit aus. Gefühlt sollte das "falsche" Id's vermeiden können.

@mumpitzstuff

Das Revolt Protokoll hat den Nachteil, dass es nicht vollständig entschlüsselt wurde. Es wurde nur ein Teil der Prüfsumme geknackt, weshalb es immer wieder vorkommen kann, dass eigentlich ungültige Telegramme als gültig erkannt werden (Prüfsumme hat auch nur 8Bit, ist also nicht besonders gut).

Klar, aber andere Protokolle haben noch nicht einmal eine Prüfsumme und funktionieren. Hast Du evtl. noch Links zur Hand, wo das Protokoll zumindest rudimentär beschrieben ist ?

@Christoph

Aber etwas vom 24.09. finde ich nicht!

deshalb schrieb ich ja auch

die ich wohl am 24.9. eingespielt hab

Kann also durchaus sein, dass das die selbe Version ist, die mahowi bereits im Mai bei sich eingespielt hat.

[pc1246]

Hallo Markus

die ich wohl am 24.9. eingespielt hab. Musst Du mal suchen....

Dies implementiert irgendwie, dass es um die Zeit eine Variante gegeben hat.
Wie gesagt, ich werde nachher mal sehen, was ich so ausrichten kann. Wenn schon die peaks und die falschen devices/logs weg sind, dann ist das schon mal gut. Ob die Daten dann wirklich bei den echten Geraeten bleiben sehe ich dann ja auch! Und dann noch den S'duino.
Gruss Christoph

[pc1246]

Moin
Kurzer Zwischenbereicht. Ein fhem mit 19_Revolt.pm mit Datum 02.17. das Andere mit Datum 05.17. Bisher keine Unterschiede, es wurden bei Beiden eine falsche Steckdose mit Plot angelegt. Allerdings kamen die Daten bei Beiden weiter auf der Richtigen an.
ESPduino hat erstmal nicht geklappt, da der 433er den CC1101 nicht erkannt hat. Wird aber erst Freitag was, da heute und morgen Stammtisch.
Gruss Christoph

[mahowi]

Ab und zu tauchen bei mir auch "falsche" Steckdosen im Log auf. Daher habe ich ja für autocreate

Code Auswählen Erweitern

attr autocreate autocreateThreshold Revolt:6:120
gesetzt. Wie KölnSolar schon gesagt hat, wird dann nur ein neues Gerät angelegt, wenn eine neue Revolt mindestens 6 Events in 120s auslöst. Seitdem wurden bei mir keine Geister-Revolts mehr angelegt.

[KölnSolar]

Ich hab mir dann gestern mal das Coding angesehen. Egal welche Version von irgendwann und irgendwoher für die 19_Revolt genommen wird: Fehlerhafte Id's werden in keinster Weise abgefangen. Lediglich Ausreisser bei den Daten. Die hab ich persönlich aber auch noch nie wahrgenommen, weshalb die irgendwo modifizierten Versionen wenig hilfreich sind.

Wie das Protokoll aufgebaut ist, ist hier recht gut beschrieben. Das ist vermutlich der Entstehungspost f. die Integration der Revolts in FHEM.

Offizielle Integration in die 00_CUL hier und weitere Entwicklung findet sich scheinbar hier. Letztere Modifikationen hab ich mir noch nicht angesehen u. kann nicht beurteilen, ob sie für das Problem eine Lösung bringen könnten und/oder ob sie zwischenzeitlich Eingang in die offiziellen Versionen gefunden haben.

Und dann gibt es noch einen umfangreichen Thread.

Fazit: Es scheint so zu sein, dass es 2 Checksummen gibt. Die erste ist ein Byte, wo simpel die Datenbytes aufaddiert sind. Die 2., so wird vermutet, ist 7bit und noch nicht entschlüsselt. Mich wundert, dass trotz der Prüfung der einfachen Checksumme Geister-Revolts(gefällt mir) angelegt werden bzw. überhaupt Protokolle mit Geister-Ids vom CUL weitergereicht werden.

Einfachste Lösung des Problems ist also sicherlich der Workaroundvon mahowi.

Für tiefergehende Analysen müsste man Informationen "mitloggen". Direkt aus dem CUL und/oder in der 19_Revolt. Das mache ich mal, dauert aber bestimmt. Und lustigerweise ist bei mir im Testsystem mit aktuellster aculfw auf einem nanoCUL u. 19_revolt aus der offiziellen Distri seit Tagen kein Geister-Revolt aufgetaucht. Meine Umgebung: ich habe 2 Dosen produktiv laufen, wobei eine sehr gut im Produktivsystem mit dem RFXTRX erkannt wird, die 2. nur sporadisch. Der nanoCUL(andere Position als der RFXTRX) empfängt die 2. Dose etwas häufiger und die 1. gar nicht.

Bisher haben wir hier ja eigentlich immer nur über die 19_revolt diskutiert. Da das Problem aber eher im CUL entsteht, sollten alle, die sich hier rege beteiligen auf die aktuellste aculfw gehen. Ich wird auch mal gucken, ob ich Unterschiede zwischen CUL_V3 u. nanoCUL bzw. S'duino feststellen kann.

Grüße Markus

[mumpitzstuff]

Code Auswählen Erweitern

my $def = $modules{REVOLT}{defptr}{$id};
  my $name = $def->{NAME};
  return "" if(IysIgnored($name));

Hiermit werden die ids im revolt Modul gefiltert denke ich. Macht auch Sinn, sonst würde eine revolt device die Nachrichten von allen anderen  empfangen.
Die Geister revolts kommen zustande weil mehrere Bits in der Nachricht kippen. Dadurch ist dann die id falsch, die prüfsumme ist aber trotzdem korrekt. Dann wird das autocreate direkt vom cul ausgelöst und nicht erst vom revolt Modul. Und manchmal kippen auch Bits in den nutzdaten und es kommt zu extremen peaks z.b. 50000 Watt oder so was. Wie oft so was passiert ist reiner Zufall und hängt von vielen Faktoren ab. Bei mir ist es früher rund 1x die Woche zu komischen werten gekommen. Geister devices kommen aber alle paar Minuten rein wenn autocreate aktiv ist.

Ich hab die culfw 1.67 drauf.

[pc1246]

Hallo
Als ich gestern angefangen habe, war der Revolt Empfang erstmal tot. Ich habe dann erstmal din CUL restarted, als ich das dann endlich gemerkt habe.
Den workaround hatte ich absichtlich nicht eingebaut, um die Unterschiede der beiden pm's sehen zu koennen.
Gruss Christoph

[masterpete23]

@masterpete: Deinen Logauszug würde ich mir etwas näher angucken. Kannst Du den bitte im vorgenannten Thread verlinken und die "richtigen" device-Id's Deiner Revolts dazu posten.

DEF  49dd
DEF  5a72

Code Auswählen Erweitern


2017.11.15 19:33:06 3: nanoCUL_433: Unknown code r49dde700023200162ea5b1b, help me!
2017.11.15 19:33:10 3: nanoCUL_433: Unknown code r5a72e6000032000000c3a06, help me!
2017.11.15 19:33:13 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a04, help me!
2017.11.15 19:33:19 3: nanoCUL_433: Unknown code r49dde700023200162ea5b1c, help me!
2017.11.15 19:33:25 3: nanoCUL_433: Unknown code r49dde700023200162ea5b1c, help me!
2017.11.15 19:33:30 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a06, help me!
2017.11.15 19:33:31 3: nanoCUL_433: Unknown code r49dde700023200162ea5b1c, help me!
2017.11.15 19:33:37 3: nanoCUL_433: Unknown code r49dde700023200162fa5b1b, help me!
2017.11.15 19:33:45 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a06, help me!
2017.11.15 19:33:46 3: nanoCUL_433: Unknown code r49dde700023200162ea5b1b, help me!
2017.11.15 19:33:51 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a06, help me!
2017.11.15 19:33:55 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a05, help me!
2017.11.15 19:33:56 3: nanoCUL_433: Unknown code r49dde700023200162ea5b1c, help me!
2017.11.15 19:34:15 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1c, help me!
2017.11.15 19:34:18 3: nanoCUL_433: Unknown code r49dde6000232001630a5b1c, help me!
2017.11.15 19:34:19 3: nanoCUL_433: Unknown code r5a72e6000032000000c3a00, help me!
2017.11.15 19:34:22 3: nanoCUL_433: Unknown code r49dde6000232001630a5b1c, help me!
2017.11.15 19:34:26 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a0b, help me!
2017.11.15 19:34:28 3: nanoCUL_433: Unknown code r49dde600023200162fa5b1c, help me!
2017.11.15 19:34:31 3: nanoCUL_433: Unknown code r49dde700023200162fa5b1c, help me!
2017.11.15 19:34:33 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a02, help me!
2017.11.15 19:34:34 3: nanoCUL_433: Unknown code r49dde700023200162fa5b1b, help me!
2017.11.15 19:34:36 3: nanoCUL_433: Unknown code r5a72e5000032000000c3aff, help me!
2017.11.15 19:34:36 3: nanoCUL_433: Unknown code r49dde600023200162fa5b1b, help me!
2017.11.15 19:34:39 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a0a, help me!
2017.11.15 19:34:43 3: nanoCUL_433: Unknown code r49dde600023200162fa5b1a, help me!
2017.11.15 19:34:46 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a03, help me!
2017.11.15 19:34:46 3: nanoCUL_433: Unknown code r49dde6000232001630a5b1b, help me!
2017.11.15 19:38:01 3: Unknown Revolt device da72, please define it
2017.11.15 19:50:43 3: Unknown Revolt device 5af2, please define it
2017.11.15 19:56:50 3: nanoCUL_433: Unknown code r49dde900023200162ea5b1e, help me!
2017.11.15 19:56:52 3: nanoCUL_433: Unknown code r49dde800023200162ea5b1b, help me!
2017.11.15 19:56:54 3: nanoCUL_433: Unknown code r5a72e7000032000000c3afb, help me!
2017.11.15 19:56:57 3: nanoCUL_433: Unknown code r5a72e5000032000000c3afb, help me!
2017.11.15 19:57:04 3: nanoCUL_433: Unknown code r5a72e6000032000000c3a03, help me!
2017.11.15 19:57:09 3: nanoCUL_433: Unknown code r49dde900023200162ea5b1b, help me!
2017.11.15 19:57:10 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a03, help me!
2017.11.15 19:57:12 3: nanoCUL_433: Unknown code r5a72e6000032000000c3afd, help me!
2017.11.15 19:57:13 3: nanoCUL_433: Unknown code r49dde800023200162ea5b1d, help me!
2017.11.15 19:57:18 3: nanoCUL_433: Unknown code r49dde800023200162ea5b1c, help me!
2017.11.15 19:59:01 3: Unknown Revolt device 5af2, please define it
2017.11.15 20:02:39 3: nanoCUL_433: Unknown code r5a72e6000032000000c3afc, help me!
2017.11.15 20:02:39 3: nanoCUL_433: Unknown code r49dde800023200162fa5b1e, help me!
2017.11.15 20:02:42 3: nanoCUL_433: Unknown code r5a72e7000032000000c3afc, help me!
2017.11.15 20:02:44 3: nanoCUL_433: Unknown code r49dde800023200162fa5b1f, help me!
2017.11.15 20:02:48 3: nanoCUL_433: Unknown code r49dde800023200162ea5b1c, help me!
2017.11.15 20:02:51 3: nanoCUL_433: Unknown code r49dde800023200162ea5b1b, help me!
2017.11.15 20:02:52 3: nanoCUL_433: Unknown code r5a72e6000032000000c3afe, help me!
2017.11.15 20:02:54 3: nanoCUL_433: Unknown code r5a72e7000032000000c3afd, help me!
2017.11.15 20:02:58 3: nanoCUL_433: Unknown code r49dde700023200162fa5b1c, help me!
2017.11.15 20:03:01 3: nanoCUL_433: Unknown code r5a72e7000032000000c3a09, help me!
2017.11.15 20:03:04 3: nanoCUL_433: Unknown code r49dde700023200162ea5b1e, help me!
2017.11.15 20:03:08 3: nanoCUL_433: Unknown code r5a72e6000032000000c3a04, help me!
2017.11.15 20:03:10 3: nanoCUL_433: Unknown code r49dde800023200162fa5b1f, help me!
2017.11.15 20:03:12 3: nanoCUL_433: Unknown code r49dde700023200162fa5b1c, help me!
2017.11.15 20:03:15 3: nanoCUL_433: Unknown code r5a72e6000032000000c3a02, help me!
2017.11.15 20:03:24 3: nanoCUL_433: Unknown code r49dde800023200162ea5b1c, help me!
2017.11.15 20:19:38 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1b, help me!
2017.11.15 20:19:40 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a03, help me!
2017.11.15 20:19:42 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1c, help me!
2017.11.15 20:24:31 3: nanoCUL_433 IT_set: Licht_wz off
2017.11.15 20:24:33 3: nanoCUL_433 IT_set: Licht_wz on
2017.11.15 20:25:22 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1d, help me!
2017.11.15 20:25:24 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a05, help me!
2017.11.15 20:25:26 3: nanoCUL_433: Unknown code r49dde4000232001630a5b1c, help me!
2017.11.15 20:25:27 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a03, help me!
2017.11.15 20:25:32 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1d, help me!
2017.11.15 20:25:34 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a04, help me!
2017.11.15 20:25:40 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1d, help me!
2017.11.15 20:25:40 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a04, help me!
2017.11.15 20:25:43 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a05, help me!
2017.11.15 20:25:44 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1d, help me!
2017.11.15 20:25:46 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a05, help me!
2017.11.15 20:25:47 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1b, help me!
2017.11.15 20:25:50 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1b, help me!
2017.11.15 20:25:59 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1c, help me!
2017.11.15 20:26:02 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a04, help me!
2017.11.15 20:26:04 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a04, help me!
2017.11.15 20:26:09 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1d, help me!
2017.11.15 20:26:16 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a05, help me!
2017.11.15 20:26:18 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a0a, help me!
2017.11.15 20:26:20 3: nanoCUL_433: Unknown code r49dde6000232001630a5b1d, help me!
2017.11.15 20:26:24 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a04, help me!
2017.11.15 20:26:27 3: nanoCUL_433: Unknown code r49dde6000232001630a5b1c, help me!
2017.11.15 20:26:28 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a02, help me!
2017.11.15 20:26:30 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1c, help me!
2017.11.15 20:26:35 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a09, help me!
2017.11.15 20:26:38 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a06, help me!
2017.11.15 20:26:39 3: nanoCUL_433: Unknown code r49dde500023200162fa5b1b, help me!
2017.11.15 20:26:41 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a04, help me!
2017.11.15 20:26:56 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a03, help me!
2017.11.15 20:27:00 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a03, help me!
2017.11.15 20:27:09 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a04, help me!
2017.11.15 20:27:10 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1b, help me!
2017.11.15 20:27:13 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a06, help me!
2017.11.15 20:27:13 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1b, help me!
2017.11.15 20:27:20 3: nanoCUL_433: Unknown code r5a72e3000032000000c3a00, help me!
2017.11.15 20:27:22 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a04, help me!
2017.11.15 20:27:22 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1b, help me!
2017.11.15 20:27:26 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a05, help me!
2017.11.15 20:27:29 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a05, help me!
2017.11.15 20:27:42 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a05, help me!
2017.11.15 20:27:43 3: nanoCUL_433: Unknown code r49dde500023200162fa5b1b, help me!
2017.11.15 20:27:46 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1b, help me!
2017.11.15 20:27:48 3: nanoCUL_433: Unknown code r5a72e5000032000000c3a02, help me!
2017.11.15 20:27:51 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a04, help me!
2017.11.15 20:27:52 3: nanoCUL_433: Unknown code r49dde500023200162fa5b1b, help me!
2017.11.15 20:28:02 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a04, help me!
2017.11.15 20:28:10 3: nanoCUL_433: Unknown code r49dde500023200162fa5b1b, help me!
2017.11.15 20:28:13 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a03, help me!
2017.11.15 20:28:14 3: nanoCUL_433: Unknown code r49dde6000232001630a5b1b, help me!
2017.11.15 20:28:17 3: nanoCUL_433: Unknown code r49dde500023200162fa5b1c, help me!
2017.11.15 20:28:26 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1b, help me!
2017.11.15 20:28:28 3: nanoCUL_433: Unknown code r5a72e4000032000000c3afc, help me!
2017.11.15 20:28:30 3: nanoCUL_433: Unknown code r5a72e4000032000000c3afe, help me!
2017.11.15 20:28:32 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1c, help me!
2017.11.15 20:28:34 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a05, help me!
2017.11.15 20:28:35 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1b, help me!
2017.11.15 20:28:41 3: nanoCUL_433: Unknown code r5a72e3000032000000c3a0e, help me!
2017.11.15 20:28:44 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a03, help me!
2017.11.15 20:28:44 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1c, help me!
2017.11.15 20:28:48 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1c, help me!
2017.11.15 20:29:35 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a06, help me!
2017.11.15 20:29:37 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1b, help me!
2017.11.15 20:29:42 3: nanoCUL_433: Unknown code r5a72e3000032000000c3a06, help me!
2017.11.15 20:29:43 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1c, help me!
2017.11.15 20:29:46 3: nanoCUL_433: Unknown code r49dde4000232001630a5b1c, help me!
2017.11.15 20:29:48 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a05, help me!
2017.11.15 20:29:49 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1b, help me!
2017.11.15 20:29:55 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a05, help me!
2017.11.15 20:29:56 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1c, help me!
2017.11.15 20:29:57 3: nanoCUL_433: Unknown code r5a72e4000032000000c3aff, help me!
2017.11.15 20:30:00 3: nanoCUL_433: Unknown code r5a72e4000032000000c3a00, help me!
2017.11.15 20:30:02 3: nanoCUL_433: Unknown code r49dde5000232001630a5b1b, help me!

[KölnSolar]

Hiermit werden die ids im revolt Modul gefiltert denke ich

wenn sie angelegt  u. auf ignored gesetzt sind, also auch ein workaround  gegen Geisterdevices

Die Geister revolts kommen zustande weil mehrere Bits in der Nachricht kippen. Dadurch ist dann die id falsch, die prüfsumme ist aber trotzdem korrekt.

Das scheint dann aber bereits in der Revolt zu passieren  oder meinst Du, dass mehrere kippen und dadurch die checksum wieder passt ? Vielleicht müsste man mal loggen, wenn die checksum nicht passt  und/oder die message, wenn das device nicht der Erwartung entspricht(hardcoded).

@masterpete23: nicht ganz das, was ich dachte. Bei den "help me" Einträgen ist das device in der message ja immer korrekt. Allerdings ist die message immer ein nibble zu lang. Das hab ich auch schon mal, aber bei weitem nicht in der Häufigkeit wie bei Dir. Dürfte nach meinem Verständnis der aculfw gar nicht vorkommen. Aber da muss ich wohl mein Verständnis verbessern  Und die anderen Meldungen sind genau die Geisterdevices. Welche Version der aculfw hast Du ?

[masterpete23]

V 1.10.02 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)

[mumpitzstuff]

Ich bin der Meinung, dass man gegen diese Geister Devices nichts machen kann. Man kann einfach nicht zwischen einer falschen Nachricht (Bits gekippt) und die trotzdem die richtigen Prüfsumme enthält von einer normalen richtig empfangenen Nachricht unterscheiden. Durch den threshold bei autocreate kann man das aber relativ gut unter Kontrolle kriegen. <device>:2:120 sollte auch ausreichend sein.

[pc1246]

Moin
Ich habe das jetzt mal ein paar Tage laufen lassen. Die treshold Loesung ist total genial, es wurden keine Phantome mehr angelegt.
Was ich allerdings seltsam finde, oder muss das so, dass die sich einfach selbst die IODEVs aussuchen. Ist mir aber schon bei mehreren devices aufgefallen!
Gruss Christoph

[mahowi]

Als IODEV wird das genommen, das den Revolt als erstes empfangen hat. Kannst Du aber nachträglich ändern.

[pc1246]

Hallo mahowi
Das ich das umstellen kann weiss ich wohl! Was mich nur wundert, dass es selbststaendig umgestellt wird, und das obwohl ich ein IODEV eingetragen habe. Oder ist das Internal LASTInputDev nicht aussagekraeftig?
Gruss Christoph

[pc1246]

Hallo zusammen
Ich werde den Thread jetzt als geloest markieren. Der workaround mit dem treshold zeigt dauerhafte Wirkung. Die gelegentlichen Ausreisser sind auch weniger geworden, so dass man die Dosen gut nutzen kann.
Danke an alle fuer die konstruktive Hilfe
Gruss Christoph

[sash.sc]

Danke

Gesendet von meinem E6653 mit Tapatalk

[mahowi]

Hallo mahowi
Das ich das umstellen kann weiss ich wohl! Was mich nur wundert, dass es selbststaendig umgestellt wird, und das obwohl ich ein IODEV eingetragen habe. Oder ist das Internal LASTInputDev nicht aussagekraeftig?
Gruss Christoph

Sorry, hatte Deinen Post gar nicht gesehen. Erklären kann ich Dir das leider auch nicht, aber auch bei mir steht in LASTInputDev ab und zu mal der nanoCUL statt dem in IODEV eingetragenen SIGNALDuino.

[Ralf9]

Wie oft sendet die Revolt Steckdose?
Werden Wiederholungen gesendet?

Wenn ausreichend viele Wiederholungen gesendet werden, gibt es evtl beim Signalduino eine Möglichkeit.

Gruß Ralf

[sash.sc]

Wie oft sendet die Revolt Steckdose?
Werden Wiederholungen gesendet?

Wenn ausreichend viele Wiederholungen gesendet werden, gibt es evtl beim Signalduino eine Möglichkeit.

Gruß Ralf

Ca. Alle 30 Sekunden werden die Daten gesendet

Gesendet von meinem E6653 mit Tapatalk