OWX asynchron überarbeitet

[Starkstrombastler]

Hallo,

ich habe aktuell ein neues Phänomen:

Nach Aufruf des OWX-ASYNC-Interfaces über die Weboberfläche
get OWusb devices
erhalte ich folgende Antwort:
interface DS2480 not active at ./FHEM/00_OWX_ASYNC.pm line 997.

Im Logfile erscheint:

Code Auswählen Erweitern

2014.07.20 23:09:20.183 1: /dev/ttyUSB0 disconnected, waiting to reappear (OWusb)
2014.07.20 23:09:20.515 1: /dev/ttyUSB0 reappeared (OWusb)

Hat jemand eine Idee, was da bei mir los ist?

[ntruchsess]

allo Christian, hallo T. Ihmann, hallo Detlef, hallo Starkstrombastler,

OWTHERM: Could not get values from device Haustuer_Temp, return was Can't call method "poll" without a package or object reference

get alarm, get temperature, get present führen alle zu dem "poll"-Fehler.

get OWusb devices
erhalte ich folgende Antwort:
interface DS2480 not active at ./FHEM/00_OWX_ASYNC.pm line 997.

Das habe ich gerade behoben und ins SVN commited. Da war in der Disconnect-erkennung ein Fehler, der bei den 'get'-befehlen den Adapter fälschlicherweise als disconnected erkannt (und deinitialisiert) hat.

flotiert zwischen PRESEN 0 und 1

Das könnte damit eventuell auch behoben sein, hatte aber keine Zeit das genauer zu untersuchen....

Nochmal eine Nachfrage: Bei OWTHERM gibt es ja das Attribut tempconv, bei dem ONKICK vorgeschlagen wird. Benutze ich dieses Attribut, werden die Temp-Devices nicht mehr aktualsiert. Ist dieses Attribut noch eine "Altlast" oder was muss ich mir da vorstellen?

am OWX_ASYNC-device muss das Attribut 'dokick' auf 1 stehen, dann werden alle OWTHERM-devices bei denen tempConv auf 'onkick' steht im intervall des OWX_ASYNC-devices ausgelesen. Ist nicht direkt eine Altlast, der Gewinn dadurch ist beim asynchronen OWX alledings eher gering, weil die OWTHERMs ja beim Auslesen nicht mehr alles für 1 Sekunde blockieren. Kann man jetzt wohl getrost weglassen.

Gruß,

Norbert

[Franz Tenbrock]

Hallo
hatte bis zum update vorgestern mein 1wire prima am laufen.
nun geht gar nichts mehr.

hab im 1 Wire Rubrik den Hinweis gefunden hier gäbs die passende Diskussion
Bin ja bereit zu lesen
aber das ist im Moment etwas zu viel, weil ja uahc vieleFehler diskutiert werden

Schade das es im Wiki nichts gibt, dann könnte man dort nachschauen wie es funktioniert, was geändert werden muss.

Kann mich einer kurz anschieben ? Bin zur Zeit beruflich voll ausgelastet...

Hier mein cfg code ( einige Zeilen , den Rest bekomme ich dann schon hin )

Code Auswählen Erweitern

########################################################################
###########    1 Wire mit OWX   Temperaturen etc
#########################################################################

define USB9097 OWX /dev/ttyUSB0
attr USB9097 buspower real
attr USB9097 dokick 1
attr USB9097 loglevel 1
attr USB9097 room OWX
attr USB9097 verbose 5

#################     Heizung_VL ####################################

define Heizung_VL OWTHERM DS18B20 4A83CE040000
attr Heizung_VL IODev USB9097
attr Heizung_VL alias Heizung_VL
attr Heizung_VL group Temperatur
attr Heizung_VL model DS1822
attr Heizung_VL room OWX
attr Heizung_VL tempHigh 75
attr Heizung_VL tempLow 70
# attr Heizung_VL icon sani_heating_temp

define FileLog_Heizung_VL FileLog ./log/Heizung_VL-%Y.log Heizung_VL|Heizung_VL
attr FileLog_Heizung_VL logtype text
attr FileLog_Heizung_VL room OWX
define SVG_FileLog_Heizung_VL SVG FileLog_Heizung_VL:SVG_FileLog_Heizung_VL:CURRENT
attr SVG_FileLog_Heizung_VL group Test
attr SVG_FileLog_Heizung_VL plotsize 550,150
attr SVG_FileLog_Heizung_VL room OWX

[ntruchsess]

DS9097-Adapter werden von OWX_ASYNC (noch nicht) unterstützt, ich arbeite aber schon daran. Das 'normale' OWX funktioniert aber eigentlich (nach meinen eigenen Tests hier) unverändert weiter. Was gibt's bei Dir denn für Fehlermeldungen?

Gruß,

Norbert

[Franz Tenbrock]

Hallo
Danke schon mal auch wenn es noch nicht hilft

Wenn ich mit get einen temp Wert holen will kommt das hier

OWTHERM: Could not get values from device Heizung_VL, return was 28.4A83CE040000.93 has returned invalid data

der dougie counter in der zisterne liefert  das hier

OWCOUNT: Could not get values from device Zisterne, reason: OWCOUNT: Could not get values from device Zisterne, reason: 1D.A2D993000002.89 has returned invalid dataOWCOUNT: Could not get values from device Zisterne, reason: 1D.A2D993000002.89 has returned invalid data


Ich hatte auch einen Kabelbruch am Stecker zum usb adapter, der ist aber wieder ok, hat das also eher nciht mit dem owx asyn zu tun?

Kabel im keller hatte ich eigentlich nicht angefasst
werde das aber auch wohl noch prüfen müssen ( in einer blöden engen ecke )

[ntruchsess]

hat das also eher nciht mit dem owx asyn zu tun?

Wenn in Deiner fhem.cfg wie bisher 'OWX' drinsteht, dann hat es mit OWX_ASYNC nichts zu tun.

Gruß,

Norbert

[ntruchsess]

OWX_ASYNC unterstützt ab heute das attribut 'buspower'.

Stellt man es auf 'parasitic', dann werden alle Aktionen auf dem 1-Wire bus streng serialisiert, so dass nichts in die Pause einer Temperaturwandlung hineinfunken kann.

Damit sollten Probleme bei parasitärer Stromversorgung in den Griff zu kriegen sein. Nachteilig ist der damit einhergehende reduzierte Durchsatz auf dem 1-Wire bus. Die Verarbeitung ist aber weiterhin asynchron, so dass das übrige FHEM nicht gebremst wird.

Ist ins SVN committet und kann in Kürze per update bezogen werden.

Gruß,

Norbert

[cwagner]

Hallo Norbert,

habe alle updates der OWX(ASYNC)-Module jeweils mitgenommen und stelle fest, dass trotz nun 30-Sekunden-Takt, die Fehlermeldungen drastisch zurückgegangen sind. Selbst auf meinem lahmen System läuft es jetzt gut. Ganz vereinzelt (1-2mal am Tag bei 60.000 Meßvorgängen) erhalte ich:

Code Auswählen Erweitern

2014.08.03 09:14:44 4: OWX_ASYNC_RunTasks: Fortluft task Error: invalid CRC at ./FHEM/21_OWTHERM.pm line 923.
2014.08.02 19:13:02 4: OWX_ASYNC_RunTasks: Zuluft task Error: OWX_DS2480 read timeout, bytes read: 9, expected: 11 at ./FHEM/OWX_DS2480.pm line 135.

Sehr herzlichen Dank für den tollen Job, den Du gemacht hast.

Christian

[ntruchsess]

Ganz vereinzelt (1-2mal am Tag bei 60.000 Meßvorgängen) erhalte ich:

Code Auswählen Erweitern

2014.08.03 09:14:44 4: OWX_ASYNC_RunTasks: Fortluft task Error: invalid CRC at ./FHEM/21_OWTHERM.pm line 923.
[...]
Sehr herzlichen Dank für den tollen Job, den Du gemacht hast.

Hallo Christian,

prima, danke für die Blumen. Mit einer Fehlerrate im >0.1% Bereich kann man glaube ich leben Wobei ich bei Gelegenheit einen automatischen Retry einbauen werde, damit käme man dann in den ppm-Bereich (solange keine systematischen Fehler vorliegen).

Gruß,

Norbert

[fhem-challenge]

OWX_ASYNC unterstützt ab heute das attribut 'buspower'.

Stellt man es auf 'parasitic', dann werden alle Aktionen auf dem 1-Wire bus streng serialisiert, so dass nichts in die Pause einer Temperaturwandlung hineinfunken kann.

Damit sollten Probleme bei parasitärer Stromversorgung in den Griff zu kriegen sein. Nachteilig ist der damit einhergehende reduzierte Durchsatz auf dem 1-Wire bus. Die Verarbeitung ist aber weiterhin asynchron, so dass das übrige FHEM nicht gebremst wird.

Ist ins SVN committet und kann in Kürze per update bezogen werden.

Gruß,

Norbert

Hallo Norbert,

OWX_ASYNC lieft bei mir gut seit ca. Anfang/Mitte Juli. Nach dem Update der letzten Tage bekomme ich ein ...

Timeout at /opt/fhem/FHEM/00_OWX_ASYNC.pm line 1059.

... OWX geht hingegen.

Viele Grüße!

Andreas


Timeout at /opt/fhem/FHEM/00_OWX_ASYNC.pm line 1059.

[ntruchsess]

Timeout at /opt/fhem/FHEM/00_OWX_ASYNC.pm line 1059.

Wenn Du (bzw. fhem) was mach(s)t? Die Zeilennummer sagt mir, dass da ein 'get' oder 'set' gelaufen ist (was genau kann man da nicht sehen).

Gruß,

Norbert

[det.]

Hallo Norbert,
das Timeout at ./FHEM/00_OWX_ASYNC.pm line 1059. kommt nach einem get .. devices.
Das wäre zu verschmerzen, aber auf dem Produktivsystem mit 2 USB Adaptern kommen danach auch keine Werte, auf dem TestRPI geht es. Bis gestern, vor dem Update war noch alles io.

[fhem-challenge]

Hallo Norbert,
das Timeout at ./FHEM/00_OWX_ASYNC.pm line 1059. kommt nach einem get .. devices.
Das wäre zu verschmerzen, aber auf dem Produktivsystem mit 2 USB Adaptern kommen danach auch keine Werte, auf dem TestRPI geht es. Bis gestern, vor dem Update war noch alles io.

Sorry Norbert,

hatte unklar beschrieben, wobei es passiert.

Ich mache ein get |ow| devices ... oder auch alarms ... also de facto bei allen get's auf das OWX_ASYNC.

Viele Grüße!

Andreas

[sweetie-pie]

Ich mache ein get |ow| devices ... oder auch alarms ... also de facto bei allen get's auf das OWX_ASYNC.

Ich bestätige das nur mal kurz, hier auch...

[ntruchsess]

seid Ihr eigentlich alle auf dem letzten SVN-stand? Mein letzter relevanter Commit von Vorgestern (Revision 6362) ist nämlich erst heute früh unter den FHEM-code-changes aufgetaucht: http://forum.fhem.de/index.php/topic,25923.0.html
Ich weiß nicht, ob das vorher schon per fhem-update rübergekommen ist. Der Zwischenstand (Revision 6358 bis 6361) ist nämlich unvollständig, dafür habe ich die Revision 6362 nachgelegt. Die individuellen commits kommen aus meinem Git-mirror, ins SVN übertragen habe ich das eigentlich in einem Rutsch.

Gruß,

Norbert