Liebe Forumskollegen,
seit einer Weile nerven mich (bei ansonsten einwandfreier Funktion) diese Fehlermeldungen im Log.
Und zwar nur bei Port A!
Habe nun Verdrahtung vielfach kontrolliert und kann keine Ursache finden. Das Device ist ein 8fach-Switch auf Basis des DS2408 mit eigener Stromversorgung. Der Bus hat (Anfang, Mitte, Ende) kontinuierlich ohne Einbrüche 5,01 V.
Bin einigermaßen ratlos.
Und Ihr?
Christian
Auch ratlos.
Weil abgesehen von der Fehlermeldung keine weiteren Informationen gegeben werden.
pah
Welche Infos würden helfen? Es ist ein DS2408 an einem - 1 wire Adapter mit FT232RL & DS2480B chipset. Ich sende set <Device> output A ON und erhalte die genannte Fehlermeldung im Log. set <Device> output B...H ON wird die Fehlermeldung nicht gesendet.
Danke für die Bereitschaft, zu helfen.
Christian
Die aktuelle Version des Moduls OWSWITCH ist 5.11, die steht auch im SVN. Also bitte mal mit get version nachsehen, welche Version das hier ist.
In 5.11 kommt als Fehlermeldung nur etwas vor wie Could not set device XXXXX, reason: invalid data length, 2 INSTEAD OF YYY BYTES - also wie lautet der Rest der Meldung ?
LG
pah
Guten Morgen,
ups, da hatte ich nicht aufgepasst, dass die Fehlermeldung nicht vollständig in den Betreff gepasst hat. Tatsächlich lautet der Rest "instead of 1 Bytes"
Benutze die aktuellste OWSWITCH, wie sie am am 26.4. im SVN stand:
$Id: 21_OWSWITCH.pm 5523 2014-04-14 11:20:22Z ntruchsess $
(da ich unterwegs bin, kann ich aktuell kein get info auf dem System machen, sondern habe im Backup-File meiner Installation, die ich sicherheitshalber immer bei mir habe, nachgeschaut).
Ergänzend:
1. Mir scheint, dass es während der Nutzung von OWSWITCH früher oder später dazu kommt, dass nach zunächst "sauberem" Lauf (eine Handvoll Schaltvorgänge) eine dann bis zum Neustart anhaltende Situation eintritt, die bei jedem Ein-Schaltvorgang diese Fehlermeldung erzeugt.
2. In meiner Not habe ich auch bereits die "ASYNC"-Version probiert und dabei (auf Basis von nunmehr rund 24 Stunden Betrieb" bei Verbose=4 keine einzige Fehlermeldung bezüglich der Switche, insbesondere Port A erhalten.
LG
Christian
Nein, nicht get info - sondern get version. Die OWX-Version ist eine andere Zahl als die SVN Version.
Die Ergänzungen verstehe ich nicht, auch die Tatsache, dass das mit der asynchronen Version anders laufen soll. Denn die sendet dieselben Binärdaten auf den 1-Wire Bus, wie die "alte" OWX-Version.
LG
pah
Zitat von: cwagner am 30 April 2014, 10:34:15
2. In meiner Not habe ich auch bereits die "ASYNC"-Version probiert und dabei (auf Basis von nunmehr rund 24 Stunden Betrieb" bei Verbose=4 keine einzige Fehlermeldung bezüglich der Switche, insbesondere Port A erhalten.
Hast Du die im OWX asynchron überarbeitet (http://forum.fhem.de/index.php/topic,13580.msg161431.html#msg161431) verlinkte Development-version, oder was aktuell noch über update augeliefert wird benutzt?
Gruß,
Norbert
Moin,
ich habe aktuell die im SVN stehende OWX_ASYNC.pm im Einsatz.
Ich werde heute Abend die von Dir genannten übernehmen auf das System und der morgige Tag ist ja geradezu ideal, ausführlich zu testen :-)
Melde mich
Christian
Die von mir verwendete 21_OWSWITCH ist Version 5.11. Bei ihr habe ich die Beobachtung, dass beim ON-Schalten des output A den genannten Fehler bekomme:
OWSWITCH: Could not set device <name>, reason: invalid data length, 2 instead of 1 bytes
Hi Norbert,
Zitat von: ntruchsess am 30 April 2014, 14:42:23
Hast Du die im OWX asynchron überarbeitet (http://forum.fhem.de/index.php/topic,13580.msg161431.html#msg161431) verlinkte Development-version, oder was aktuell noch über update augeliefert wird benutzt?
Mit den Develogpment-Versionen bin ich in meiner Umgebung überhaupt nicht zurecht gekommen. Zunächst ersetzte ich nur die OWX_ASYNC. Da lief alles, bis mir auffiel, dass die 10 Temp-Sensoren, der 2450 mit seinen Sensoren nicht mehr weiter aktualisierten. Interval stand bei OWAD und OWTHERM jeweils auf einem Riesenwert (obwohl in der fhem.cfg Werte zwischen 10 und 300 Sekunden vorgegeben sind). Habe die Werte interaktiv auf die gewünschten korrgiert, aber jeweils nach dem ersten erfolgreichen Aktualisieren hatte ich wieder irre Werte als Intervall. So habe ich sämtliche dort genannten weiteren Module ersetzt, danach startete mein FHEM auf der Fritzbox überhaupt nicht mehr. Es gab andauernd Compilation-Errors im OWX_ASYNC beim Aufruf von Untermodulen, wie ich auf der Console sah.
Habe dann Modul für Modul wieder ersetzt mit den SVN-Versionen, und schließlich lief FHEM wieder an und auch alle Intervalle stimmen und sämtliche 22 1-Wire-Sensoren und Aktoren (10*18X20; 4 Sensoren am 2450; 2408 als 8-Fach-Switch) tun das, was ich erwarte.
Ich habe für Verbose 5 beim 2450 sowie bei 2808 einzelne, reproduzierbare Fehler (wie ich es lese: Mismatch bei Länge angeforderte bzw. gelieferte Daten), die aktuell nach meiner erst einige Stunden alten Erfahrung keine Funktionsbeeinträchtigung bedeuten, aufgezeichnet.
Falls das für Dich von Interesse und nicht ein verwirrender Rückgriff auf frühere Versionen ist, würde ich die in dem Thread #161431 ("Async überarbeitet") posten.
Zusammenfassend: Deine Arbeit an dem Thema Timing 1-Wire-Interface finde ich extrem hoch einzuschätzen, da die bisherigen etwa 2,5 Tage Betriebserfahrung meiner 1-Wire-Geräte eine deutlich bessere Agilität der Verarbeitung bei drastisch niedrigerer Belastung des Systems bedeuten. Drei Beispiele mit apptime gemessen (1. ist sync, 2. ist async)
name function max count total average maxDly
tmr-OWO_GetStatus HASH(0x1165738) 1582 18 26329 1462.72 800 HASH(0x1165738)
tmr-OWO_GetStatus HASH(0x12a6168) 1481 3 4363 1454.33 56 HASH(0x12a6168)
tmr-OWAD_GetValues HASH(0xc3c350) 1219 560 533956 953.49 8134 HASH(0xc3c350)
tmr-OWAD_GetValues HASH(0xd92698) 120 106 11454 108.06 5469 HASH(0xd92698)
tmr-OWTHERM_GetValues HASH(0xc62b78) 1893 1120 1441606 1287.15 5733 HASH(0xc62b78)
tmr-OWTHERM_GetValues HASH(0xd91fe8) 105 107 10943 102.27 388 HASH(0xd91fe8)
Herzliche Grüße
Christian
...Muss das Thema nochmal aufwärmen.
Betreibe drei OWX_29_XX0 - OWX_29_XX2 über readingsProxy.
Sowohl bei direkter Befehlseingabe (z.B set OWX_29_XX1 output H on) -als auch über RedingsProxy-
wird bei allen Schaltern A-H wird im Log folgendes protokolliert:
Could not set device OWX_29_XX0, reason: invalid data length, 2 instead of 1 bytes
Der Befehl wird aber entgegen der Fehlermeldung korrekt ausgeführt. Nur ein Schönheitsfehler? Störend aber schon...
Version:
21_OWSWITCH.pm 8513 2015-05-02 03:52:59Z pahenning
21_OWTHERM.pm 7181 2014-12-10 05:13:48Z pahenning
00_OWX.pm 6392 2014-08-11 15:25:00Z ntruchsess
By the way:
Bin ziemlich beggeistert von der OWX/ OWSWITCH Lösung.
Mit owserver/OWFS hat sich fhem andauernd aufgehängt und ließ sich nicht mehr starten.
LG
Jorge
Bitte mal mit get <devicename> version die interne Versionsnummer abfragen - die SVN-Versionen verfolge ich nicht.
LG
pah
Gerne. Hier die Versionsnummer der OWSWITCH
OWX_29_XXX.version => 5.24
ist aus dem letzten fhem-update.
Hier noch ein Auszug aus dem eventmonitor (Befehl: OWX_29_XXX output H on)
2016-02-10 17:40:13 OWSWITCH OWX_29_XX0 H: ON
2016-02-10 17:40:13 OWSWITCH OWX_29_XX0 A: ON☇ B: ON☇ C: ON☇ D: ON☇ E: ON F: ON☇ G: ON☇ H: ON
Das kriegen auch die readingsProxy mit:
2016-02-10 17:40:13 readingsProxy OWX_29_XX0.A ON☇ B: ON☇ C: ON☇ D: ON☇ E: ON F: ON☇ G: ON☇ H: ON
2016-02-10 17:40:13 readingsProxy OWX_29_XX0.H ON
damit wird der State von OWX_29_XX0.A auf ´ON☇ B: ON☇ C: ON☇ D: ON☇ E: ON F: ON☇ G: ON☇ H: ON´ gesetzt, was ja auch sicher nicht gewollt ist?
Sorry, das letzte ist wohl etwas offtopic.
LG
Jorge
OT, ja - wo ist das Problem ?
Die Fehlermeldung mus sich mir bei Gelegenheit mal ans.ehen. Ist aber "low priority", tut mir leid, da habe ich viel wichtigere Baustellen
LG
pah
OK,
Danke trotzdem.
Das Problem liegt in der Nicht-WAF ;) gerechten State-Anzeige der readingProxy. Als Workaround fange ich derweil diese im Frontend mit devStateIcon und den Regex ´ON\sB.*´ bzw. ´ON☇\sB.*´ ab.
Das Vollmüllen des Logs bleibt aber...
LG
Jorge
Vlt. doch mal einen Blick in die Doku werfen
Man braucht nur das Attribut stateS auf "X" zu setzen - schon wird aus dem extern nach Null gezogenen Input ein "ONX".
Und wenn man das noch loswerden will: Attribut eventMap auf OFF:OFF ON.*:ON setzen.
Und warum readingsProxy statt des Attribtes stateFormat verwendet wir, ist mir auch nicht einsichtig.
LG
pah