OWTHERM blockiert FHEM

[dan1180]

Hallo zusammen,

schon lange habe ich den Verdacht, dass es nicht normal ist wie langsam FHEM teilweise auf Befehle reagiert. Nun scheint sich da etwas abgezeichnet zu haben, das hier vielleicht gelöst, oder zumindest erklärt werden kann.

Ich betreibe FHEM nun seit einem halben Jahr mit 19 1wire Sensoren über OWX->OWTHERM. Nun habe ich mit meinen ersten Homematic-Komponenten begonnen und hatte Probleme, dass Befehle nicht angekommen oder Kommunikationen unterbrochen wurden. Bei der Fehleranalyse in einem anderen Thema wurde ich irgendwann nach dem Ergebnis von "apptime" gefragt. Das Ergebnis sah folgendermaßen aus:

Code Auswählen Erweitern

                                name            function    max     count  total  average  maxDly
               tmr-OWTHERM_GetValues      HASH(0x27ae330)   7416      2    14284  7142.00  11988 HASH(0x27ae330)
               tmr-OWTHERM_GetValues      HASH(0x27ae7b0)   6957      2    13814  6907.00  11742 HASH(0x27ae7b0)
               tmr-OWTHERM_GetValues      HASH(0x27aec30)   6890      2    13747  6873.50  11963 HASH(0x27aec30)
               tmr-OWTHERM_GetValues      HASH(0x2779498)   6888      2    13748  6874.00  12174 HASH(0x2779498)
               tmr-OWTHERM_GetValues      HASH(0x27936a8)   6885      2    13732  6866.00  12055 HASH(0x27936a8)
               tmr-OWTHERM_GetValues      HASH(0x27ac9c0)   6881      2    13732  6866.00  12033 HASH(0x27ac9c0)
               tmr-OWTHERM_GetValues      HASH(0x2793b28)   6880      2    13748  6874.00  12033 HASH(0x2793b28)
               tmr-OWTHERM_GetValues      HASH(0x27ace40)   6880      2    13729  6864.50  11990 HASH(0x27ace40)
               tmr-OWTHERM_GetValues      HASH(0x2792488)   6874      2    13732  6866.00  12277 HASH(0x2792488)
               tmr-OWTHERM_GetValues      HASH(0x2792908)   6873      2    13736  6868.00  12322 HASH(0x2792908)
               tmr-OWTHERM_GetValues      HASH(0x2792da8)   6870      2    13726  6863.00  12244 HASH(0x2792da8)
               tmr-OWTHERM_GetValues      HASH(0x2735de0)   6869      2    13724  6862.00  12013 HASH(0x2735de0)
               tmr-OWTHERM_GetValues      HASH(0x2792008)   6868      2    13725  6862.50  12285 HASH(0x2792008)
               tmr-OWTHERM_GetValues      HASH(0x27af0d0)   6868      2    13734  6867.00  11968 HASH(0x27af0d0)
               tmr-OWTHERM_GetValues      HASH(0x27af550)   6867      2    13726  6863.00  12093 HASH(0x27af550)
               tmr-OWTHERM_GetValues      HASH(0x2778b98)   6866      2    13720  6860.00  12101 HASH(0x2778b98)
               tmr-OWTHERM_GetValues      HASH(0x2779918)   6866      2    13714  6857.00  12146 HASH(0x2779918)
               tmr-OWTHERM_GetValues      HASH(0x2779018)   6864      2    13727  6863.50  12081 HASH(0x2779018)
               tmr-OWTHERM_GetValues      HASH(0x2793228)   6863      2    13702  6851.00  12345 HASH(0x2793228)
                              HMLAN1           HMLAN_Read    142     11      663    60.27      0 HASH(0x2219840)
         FHEMWEB:192.168.2.103:51120              FW_Read    120      6      153    25.50      0 HASH(0x2ad4e98)


Daraus kann man sehen, dass OWTHERM mein FHEM für 7 Sek. blockiert. Ich habe mittlerweile auch Messungen über 11 Sek. Der Auszug aus meiner fhem.cfg sieht so aus:

Code Auswählen Erweitern

#define OWio1 OWX /dev/ttyUSB0
#attr OWio1 buspower parasitic
#attr OWio1 group 1Wire
#attr OWio1 room Controller

#define FBH_RL OWTHERM DS1820 F39FAA020800
#attr FBH_RL IODev OWio1
#attr FBH_RL fp_Heizung 505,670,0,
#attr FBH_RL group Sensoren
#attr FBH_RL interval 300
#attr FBH_RL model DS1820
#attr FBH_RL room Heizung
#attr FBH_RL stateFormat {sprintf("%.1f",ReadingsVal("FBH_RL","temperature",0))."°C"}
#attr FBH_RL tempHigh 100
#attr FBH_RL tempLow 0

#define FBH_VL OWTHERM DS1820 4199AA020800
#attr FBH_VL IODev OWio1
#attr FBH_VL fp_Heizung 405,670,0,
#attr FBH_VL group Sensoren
#attr FBH_VL interval 300
#attr FBH_VL model DS1820
#attr FBH_VL room Heizung
#attr FBH_VL stateFormat {sprintf("%.1f",ReadingsVal("FBH_VL","temperature",0))."°C"}
#attr FBH_VL tempHigh 100
#attr FBH_VL tempLow 0

#define WHK_RL OWTHERM DS1820 80B0AA020800
#attr WHK_RL IODev OWio1
#attr WHK_RL fp_Heizung 335,670,0,
#attr WHK_RL group Sensoren
#attr WHK_RL interval 300
#attr WHK_RL model DS1820
#attr WHK_RL room Heizung
#attr WHK_RL stateFormat {sprintf("%.1f",ReadingsVal("WHK_RL","temperature",0))."°C"}
#attr WHK_RL tempHigh 75
#attr WHK_RL tempLow 70

#define WHK_VL OWTHERM DS1820 F29CAA020800
#attr WHK_VL IODev OWio1
#attr WHK_VL fp_Heizung 235,670,0,
#attr WHK_VL group Sensoren
#attr WHK_VL interval 300
#attr WHK_VL model DS1820
#attr WHK_VL room Heizung
#attr WHK_VL stateFormat {sprintf("%.1f",ReadingsVal("WHK_VL","temperature",0))."°C"}
#attr WHK_VL tempHigh 75
#attr WHK_VL tempLow 70

#define OBK_LT OWTHERM DS1820 1FAFAA020800
#attr OBK_LT IODev OWio1
#attr OBK_LT fp_Heizung 510,120,0,
#attr OBK_LT group Sensoren
#attr OBK_LT interval 300
#attr OBK_LT model DS1820
#attr OBK_LT room Heizung
#attr OBK_LT stateFormat {sprintf("%.1f",ReadingsVal("OBK_LT","temperature",0))."°C"}
#attr OBK_LT tempHigh 75
#attr OBK_LT tempLow 70

#define OBK_RL OWTHERM DS18B20 BC935E050000
#attr OBK_RL IODev OWio1
#attr OBK_RL fp_Heizung 405,280,0,
#attr OBK_RL group Sensoren
#attr OBK_RL interval 300
#attr OBK_RL model DS18B20
#attr OBK_RL room Heizung
#attr OBK_RL stateFormat {sprintf("%.1f",ReadingsVal("OBK_RL","temperature",0))."°C"}
#attr OBK_RL tempHigh 75
#attr OBK_RL tempLow 70

#define OBK_VL OWTHERM DS1820 839BAA020800
#attr OBK_VL IODev OWio1
#attr OBK_VL fp_Heizung 505,280,0,
#attr OBK_VL group Sensoren
#attr OBK_VL interval 300
#attr OBK_VL model DS1820
#attr OBK_VL room Heizung
#attr OBK_VL stateFormat {sprintf("%.1f",ReadingsVal("OBK_VL","temperature",0))."°C"}
#attr OBK_VL tempHigh 75
#attr OBK_VL tempLow 70

#define SSP_UU OWTHERM DS1820 6291AB020800
#attr SSP_UU IODev OWio1
#attr SSP_UU fp_Heizung 505,480,0,
#attr SSP_UU group Sensoren
#attr SSP_UU interval 300
#attr SSP_UU model DS1820
#attr SSP_UU room Heizung
#attr SSP_UU stateFormat {sprintf("%.1f",ReadingsVal("SSP_UU","temperature",0))."°C"}
#attr SSP_UU tempHigh 75
#attr SSP_UU tempLow 70

#define SSP_UM OWTHERM DS1820 211BAB020800
#attr SSP_UM IODev OWio1
#attr SSP_UM fp_Heizung 390,480,0,
#attr SSP_UM group Sensoren
#attr SSP_UM interval 300
#attr SSP_UM model DS1820
#attr SSP_UM room Heizung
#attr SSP_UM stateFormat {sprintf("%.1f",ReadingsVal("SSP_UM","temperature",0))."°C"}
#attr SSP_UM tempHigh 75
#attr SSP_UM tempLow 70

#define SSP_MM OWTHERM DS1820 55B7AA020800
#attr SSP_MM IODev OWio1
#attr SSP_MM fp_Heizung 275,480,0,
#attr SSP_MM group Sensoren
#attr SSP_MM interval 300
#attr SSP_MM model DS1820
#attr SSP_MM room Heizung
#attr SSP_MM stateFormat {sprintf("%.1f",ReadingsVal("SSP_MM","temperature",0))."°C"}
#attr SSP_MM tempHigh 75
#attr SSP_MM tempLow 70

#define SSP_OM OWTHERM DS1820 889DAA020800
#attr SSP_OM IODev OWio1
#attr SSP_OM fp_Heizung 155,480,0,
#attr SSP_OM group Sensoren
#attr SSP_OM interval 300
#attr SSP_OM model DS1820
#attr SSP_OM room Heizung
#attr SSP_OM stateFormat {sprintf("%.1f",ReadingsVal("SSP_OM","temperature",0))."°C"}
#attr SSP_OM tempHigh 75
#attr SSP_OM tempLow 70

#define SSP_OO OWTHERM DS1820 2E0EAB020800
#attr SSP_OO IODev OWio1
#attr SSP_OO fp_Heizung 50,480,0,
#attr SSP_OO group Sensoren
#attr SSP_OO interval 300
#attr SSP_OO model DS1820
#attr SSP_OO room Heizung
#attr SSP_OO stateFormat {sprintf("%.1f",ReadingsVal("SSP_OO","temperature",0))."°C"}
#attr SSP_OO tempHigh 75
#attr SSP_OO tempLow 70

#define FSK_RL OWTHERM DS18B20 F8F35E050000
#attr FSK_RL IODev OWio1
#attr FSK_RL fp_Heizung 235,280,0,
#attr FSK_RL group Sensoren
#attr FSK_RL interval 300
#attr FSK_RL model DS18B20
#attr FSK_RL room Heizung
#attr FSK_RL stateFormat {sprintf("%.1f",ReadingsVal("FSK_RL","temperature",0))."°C"}
#attr FSK_RL tempHigh 75
#attr FSK_RL tempLow 70

#define FSK_VL OWTHERM DS18B20 73735F050000
#attr FSK_VL IODev OWio1
#attr FSK_VL fp_Heizung 335,280,0,
#attr FSK_VL group Sensoren
#attr FSK_VL interval 300
#attr FSK_VL model DS18B20
#attr FSK_VL room Heizung
#attr FSK_VL stateFormat {sprintf("%.1f",ReadingsVal("FSK_VL","temperature",0))."°C"}
#attr FSK_VL tempHigh 75
#attr FSK_VL tempLow 70

#define KOL_RL OWTHERM DS18B20 3C3A5F050000
#attr KOL_RL IODev OWio1
#attr KOL_RL fp_Heizung 40,280,0,
#attr KOL_RL group Sensoren
#attr KOL_RL interval 300
#attr KOL_RL model DS18B20
#attr KOL_RL room Heizung
#attr KOL_RL stateFormat {sprintf("%.1f",ReadingsVal("KOL_RL","temperature",0))."°C"}
#attr KOL_RL tempHigh 75
#attr KOL_RL tempLow 70

#define KOL_VL OWTHERM DS18B20 68F45E050000
#attr KOL_VL IODev OWio1
#attr KOL_VL fp_Heizung 135,280,0,
#attr KOL_VL group Sensoren
#attr KOL_VL interval 300
#attr KOL_VL model DS18B20
#attr KOL_VL room Heizung
#attr KOL_VL stateFormat {sprintf("%.1f",ReadingsVal("KOL_VL","temperature",0))."°C"}
#attr KOL_VL tempHigh 75
#attr KOL_VL tempLow 70

#define FSK_LT OWTHERM DS18B20 DD5E5E050000
#attr FSK_LT IODev OWio1
#attr FSK_LT fp_Heizung 335,120,0,
#attr FSK_LT group Sensoren
#attr FSK_LT interval 300
#attr FSK_LT model DS18B20
#attr FSK_LT room Heizung
#attr FSK_LT stateFormat {sprintf("%.1f",ReadingsVal("FSK_LT","temperature",0))."°C"}
#attr FSK_LT tempHigh 75
#attr FSK_LT tempLow 70

#define AUT_ND OWTHERM DS18B20 80CB5E050000
#attr AUT_ND IODev OWio1
#attr AUT_ND fp_Heizung 90,855,0,
#attr AUT_ND group Sensoren
#attr AUT_ND interval 300
#attr AUT_ND model DS18B20
#attr AUT_ND room Heizung
#attr AUT_ND stateFormat {sprintf("%.1f",ReadingsVal("AUT_ND","temperature",0))."°C"}
#attr AUT_ND tempHigh 75
#attr AUT_ND tempLow 70

#define KOL_LT OWTHERM DS18B20 D00E5F050000
#attr KOL_LT IODev OWio1
#attr KOL_LT group Sensoren
#attr KOL_LT interval 300
#attr KOL_LT model DS18B20
#attr KOL_LT room Heizung
#attr KOL_LT stateFormat {sprintf("%.1f",ReadingsVal("KOL_LT","temperature",0))."°C"}
#attr KOL_LT tempHigh 75
#attr KOL_LT tempLow 70


Wie ihr seht sind die Sensoren und der OWX alle (seit heute testweise) deaktiviert. Und siehe da, fhem schält fast schon die Seiten um bevor ich die Maustaste wieder losgelassen habe.

Habe ich einen Fehler in meinen Definitionen oder kann mir jemand einen anderen Hinweis geben, wie ich das beheben kann.

Vielen Dank für jeden Hinweis!

[det.]

Da fehlen leider noch paar Angaben über den Busmaster, Bustopologie etc.
Was mir als erstes auffällt, Du betreibst den Bus ohne extra Spannungsversorgung der Sensoren (Buspower parasitic) Dann sind bei der Anzahl der Thermometer die Verzögerungen normal. Schau mal nach OWX_ASYNC im Forum - damit sollte es gehen und immer mit stabiler 5V aktiver Spannungsversorgung der Sensoren.

[dan1180]

Eigentlich habe ich aber einen (selbstgebauten, http://www.fhemwiki.de/wiki/Datei:Passives_Interface.png) DS9097 mit Spannungsversorgung (der obere) und diesen sogar noch über einen Spannungsversorgten USB-Hub angeschlossen. Muss ich das FHEM dann auch sagen oder müsste das dann von alleine schneller gehen?

[Joachim]

attr <name> buspower real|parasitic
tells FHEM whether power is supplied to the 1-Wire bus or not.

[ntruchsess]

Eigentlich habe ich aber einen DS9097 mit Spannungsversorgung [...] Muss ich das FHEM dann auch sagen oder müsste das dann von alleine schneller gehen?

einen DS9097 erkennt FHEM von alleine. (Davon wird es aber nicht schneller )

Schau mal nach OWX_ASYNC im Forum - damit sollte es gehen und immer mit stabiler 5V aktiver Spannungsversorgung der Sensoren.

OWX_ASYNC unterstützt bisher nur FRM und DS2480 als Busmaster. Den DS9097 würde ich unterstützen, wenn ich einen hätte. Bauteile beschaffen und selber löten hat im Augenblick recht niedrige Priorität.

Die Verzögerungen kommen daher, dass OWTHERM beim normalen OWX bei jeder Themperaturmessung den DS18B20 erst triggern und nach Abschluss der Messung (ca. 1 Sekunde Verzögerung) auslesen kann. Die Sekunde Verzögerung erfolgt mit OWX immer synchron (d.h. einfach durch Anhalten des Prozesses). 19 Sensoren machen damit 19 Sekunden Wartezeit, verteilt auf das Wiederholinterval.
Bei OWX_ASYNC läuft fhem zwischem dem Trigger und dem Auslesen weiter.

Das mit dem Attribut 'buspower=real' funktioniert aktuell wohl nicht so wie es soll. Da passt OWTHERM und OWX nicht ganz zusammen, in OWX kann man das Attribut 'buspower' setzen, in OWTHERM wird aber auf ein im OWX-device gesetztes Attribut 'doKick' getestet (das man dort gar nicht setzen kann, Pah hat hier im OWTHERM eine Änderung aus der Entwicklungsversion von OWX vorweggenommen). Ich werde das im OWX aber gleich mal anpassen. Die Idee ist, OWX triggert die Temperaturmessung aller DS18B20 auf einmal (das geht, indem man für den Befehl keine 1-Wire addresse angibt, dann werden alle gleichzeitig angesprochen). Die OWTHERM-devices sollen dann (wenn sie mit dem Attribut 'tempConv=onKick' dafür konfiguriert sind) ihren eigenen Trigger überspringen und direkt die DS18B2 auslesen.
Weil die DS18B20 beim Messen der Themperatur einen erhöhten Strombedarf haben, kann man diesen Messmodus nur mit echter 5V-Stromversorgung nutzen. Bei parasitärer Stromversorgung würde die Spannung während der parallelen Thermperaturmessung zusammenbrechen, wenn zu viele Sensoren gleichzeitig am Bus hängen.

Gruß,

Norbert

[ntruchsess]

Das mit dem Attribut 'buspower=real' funktioniert aktuell wohl nicht so wie es soll.

Ich habe das im OWX grade mal angepasst. Es gibt jetzt ein Attribut 'dokick=0|1', wg. der Abwärtskompatibilität wird dieses implizit mitgesetzt, wenn 'buspower=real' gesetzt ist. (dokick=1 ist quasi ein Synonym für buspower=real). In OWX_ASYNC gibt's sowieso nur noch dokick

Zusätzlich habe ich gleich noch ein Attribut 'interval' dazugepackt, damit man das kick-interval auch dauerhaft setzen kann.

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Das stimmt so aber  nicht.

Die "Entwicklerversion" von OWX steht hier schon länger zur Verfügung - und die kennt das alte Attribut "buspower" überhaupt nicht mehr. In dem hier  bereits vor Monaten veröffentlichten OWX gibt es vielmehr die beiden folgenden Attribute:

Code Auswählen Erweitern


# set <name> interval <seconds>     => set period for temperature conversion and alarm testing
# attr <name> dokick 0/1            => 1 if the interface regularly kicks thermometers on the
#                                      bus to do a temperature conversion,
#                                      0 if not


Dass ntruchsess dies jetzt ins Haupt-OWX übernommen hat, ist OK - aber wir müssen erheblich aufpassen, dass hier nicht ein vollkommener Modulwirrwarr entsteht.

Gerne kann ntruchsess ja Werbung für sein OWX_ASYNC machen - aber meines Wissens läuft das richtig stabil erst mit seinen Arduinos, und noch nicht mit den seriellen oder Arduino-Busmastern.

Unabhängig davon: Eine Blockade von 7 Sekunden für eine Temperaturmessung sollte auch beim "alten" OWX in keiner Weise vorkommen, da tritt noch irgendein anderer Fehler auf. Der Knackpunkt ist hierbei tatsächlich der DS9097, denn der ist intern so unintelligent, dass die gesamte Bus-Suche nach irgendwelchen Devices von FHEM übernommen werden muss. Bei 19 angeschlossenen Sensoren kann das durchaus so lahm werden, weil bei einer ungünstigen Verteilung der ID's ein erheblicher Teil des Suchbaums abgegrast werden muss.

Also erster Schritt: Bitte statt des "doofen" DS9097 bitte ein Interface mit echtem Busmaster einbauen, der die Bus-Suche selbst erledigen kann und damit nicht FHEM belastet.

LG

pah

[ntruchsess]

Dass ntruchsess dies jetzt ins Haupt-OWX übernommen hat, ist OK - aber wir müssen erheblich aufpassen, dass hier nicht ein vollkommener Modulwirrwarr entsteht.

Bin ich ganz bei Dir, nur verwendet der Normaluser halt nicht die Versionen, die hier vor Monaten in einem Thread angehängt waren, sondern maximal das, was im SVN zu finden und per update zu installieren ist.
Die Entwicklerversion 'von vor Monaten' hat irgendwie auch niemand so richtig durchtesten wollen - zum CUNO habe ich z.B. null Feedback und zum selber Testen habe ich keinen. Das war mir zu heikel das bestehende OWX damit einfach so zu ersetzen. Risiko-minimierung ist auch der primäre Grund, warum ich den asynchronen Modus jetzt in das OWX_ASYNC-modul abgetrennt habe. Das ist so, wie es jetzt ist (gemeinsamer code für alle Backends in den Frontend-modulen) erheblich besser zu beherrschen.

Gerne kann ntruchsess ja Werbung für sein OWX_ASYNC machen

darum gings mir jetzt grad gar nicht, ich möchte da auch nicht konkurrieren, sondern kooperieren. Ich wollte einfach nur erklären, wo bei 19 Themperatursensoren die Zeit bleiben kann. Wenn die alle (ohne dokick/tempConv=onkick) eigenständig und synchron pollen, dann wartet man leicht mal ein paar Sekunden aufs Webinterface, wenn man zur falschen Zeit klickt (Ganz unabhängig vom verwendeten Busmaster). Mit dokick=1 + tempConv=onKick sollte das normale OWX auch mit einem DS9097 passable Antwortzeiten erreichen.
Man darf beim DS9097 natürlich nicht dauernd mit 'get xxx present' Bussuchen triggern und dann mit flotten Antwortzeiten rechnen
Ein ordentlicher Busmaster kann die Situation natürlich nur verbessern...

Gruß,

Norbert

[Prof. Dr. Peter Henning]

Hallo Norbert,

das passt schon. Wir müssen uns nur mal über eine klare Architektur und Aufteilung einigen. Ich mach mal ein Diagramm dazu - das hilft auch den Anwendern, sich für eine Lösung zu entscheiden.

LG

pah

P.S.: Ich habe gar nicht gegen Konkurrenz, die belebt das Geschäft

[Joachim]

Die Entwicklerversion 'von vor Monaten' hat irgendwie auch niemand so richtig durchtesten wollen

Danke Norbert, dass Du mich als niemand bezeichnest. Das habe ich hiermit zur Kenntniss genommen.
http://forum.fhem.de/index.php/topic,13580.60.html

Gruß Joachim

[Prof. Dr. Peter Henning]

@Joachim:

@Norbert: Bitte im Moment mal keine neuen Commits für OWCOUNT - habe da ein paar Dinge aufgeräumt und muss erst testen. Außerdem noch einen Fehler in Zeile 762 behoben.

LG

pah

[ntruchsess]

Danke Norbert, dass Du mich als niemand bezeichnest. Das habe ich hiermit zur Kenntniss genommen.

Hallo Joachim (und alle anderen, die sich vieleicht angesprochen gefühlt haben),

Da bin ich wohl in einen Fettnapf gestiegen, das tut mir ausgesprochen leid. Dein Feedback war immer sehr wertvoll für mich. Darf ich Dich aufrichtig um Entschuldigung für meine unbedachte Äußerung bitten?
Irgendwie war mein Bezug auch nicht klar. Die 'Entwicklerversion', die 'hier schon seit Monaten' zur Verfügung steht habe ich auf diesen Post von Pah bezogen (Die in diesem Post angehängten Dateien sind unser erstes synchrones Refactoring der 00_OWX.pm). An die darauf aufbauende asynchrone Überarbeitung habe ich dabei nicht weiter gedacht.

Gruß,

Norbert

[Joachim]

Da bin ich wohl in einen Fettnapf gestiegen

aber mitten hinein, so ist das nun mal mit den aufblasbaren Fettnäpfen, habe auch immer ein paar dabei.
Entschuldigung angenommen.

Gruß Joachim

[ntruchsess]

@Norbert: Bitte im Moment mal keine neuen Commits für OWCOUNT - habe da ein paar Dinge aufgeräumt und muss erst testen. Außerdem noch einen Fehler in Zeile 762 behoben.

Schön, dass Du wieder an Board bist

Nur zu meinem Verständnis: was ist an Zeile 762: $ret1 = OWCOUNT_GetPage($hash,14,0); denn falsch? Es ist Absicht, dass der optionale 4. Parameter 'sync' nicht gesetzt ist, da das in Zeile 763 folgende '$ret2 = OWCOUNT_GetPage($hash,15,1,1);' sowieso wartet, bis beide GetPage-Aufrufe fertig sind. Den ersten OWCOUNT_GetPage synchron ausführen zu lassen schadet natürlich nicht, macht im Ergebnis aber keinen Unterschied.

Oder meinst Du eine andere Zeile 762?

Gruß,

Norbert

[dan1180]

Ähm...hallo?! Ich komm da jetzt nicht mehr mit

Wenn ich das also richtig verstehe, kann ich mit meinem selbstgebauten (und ich war so stolz darauf) DS9097 einpacken. Weil der die Sensoren nicht selber ließt und die Temoeraturen an FHEM weitergibt sondern FHEM die ganze Arbeit machen lässt? Was könnt ihr mir für (gute und günstige) Alternativen anbieten? Ich löte auch gerne selber wieder was zusammen

...und warum kann ich jetzt meinen OWX nicht mehr aktivieren? Hab alle "#" wieder gelöscht und bekommen nur noch "OWX failed". Auch digitemp gibt mir keine Temoeraturen mehr aus. Erkannt werden aber noch alle...