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:
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:
#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!
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.
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?
Zitatattr <name> buspower real|parasitic
tells FHEM whether power is supplied to the 1-Wire bus or not.
Zitat von: dan1180 am 13 April 2014, 23:40:37
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 ;-))
Zitat von: det. am 13 April 2014, 23:26:19
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
Zitat von: ntruchsess am 14 April 2014, 11:09:47
Das mit dem Attribut 'buspower=real' funktioniert aktuell wohl nicht so wie es soll.
Ich habe das im OWX grade mal angepasst (https://github.com/ntruchsess/fhem-mirror/commit/1e895e7b735c41a8beab42d788fa31e65e0e8dcf). 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
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:
# 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
Zitat von: Prof. Dr. Peter Henning am 14 April 2014, 17:03:49
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.
Zitat von: Prof. Dr. Peter Henning am 14 April 2014, 17:03:49
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
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 ;D
ZitatDie 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
@Joachim: ;D
@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
Zitat von: Joachim am 14 April 2014, 20:33:22
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 (http://forum.fhem.de/index.php/topic,18808.msg125977.html#msg125977) 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
ZitatDa 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
Zitat von: Prof. Dr. Peter Henning am 14 April 2014, 21:30:46
@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); (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/21_OWCOUNT.pm#L762) 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
Ä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...
günstige Alternative (zum selberlöten): USB-Interface_für_1-Wire (http://www.fhemwiki.de/wiki/USB-Interface_f%C3%BCr_1-Wire). Den verwendeten FT232RL kauft man ab besten als fertiges Modul mit USB-buchse auf eBay ab 5 EUR, dann gibt man für die ganze Schaltung keine 15 EUR aus.
Das gleiche von Damian hier im Forum (http://forum.fhem.de/index.php/topic,20923.0.html) fertig aufgebaut angeboten (falls er noch welche hat). Konkurenzlos günstiger Preis (finde ich...). Funktioniert hier bei mir astrein ;-)
Oder Arduino (http://www.fhemwiki.de/wiki/Arduino_mit_OneWireFirmata), braucht nur einen externen Pull-up-wiederstand als zusätzliche Beschaltung, auf eBay ab ca. 7 EUR (Arduino-clones aus China, ein Nano V3 genügt, sollte nur 32kb Flash oder mehr haben).
Die Problematik der Delays beim 'normalen' OWX mit OWTHERM (und die oben angesprochenen Lösungsmöglichkeiten) besteht allerdings unabhängig vom verwendeten Busmaster. Der DS9097 braucht halt etwas mehr Rechenleistung im FHEM, das wars dann aber schon. Wichtiger ist da eher, dass die 'echten' Busmaster elektrisch besser auf den Bus angepasst sind, also eher längere Buslängen erlauben, als der rein passive Adapter.
Gruß,
Norbert
Hallo Norbert,
OK, habe Deine Änderungen noch nicht soweit nachvollzogen, dass ich gemerkt habe, dass Du je nach Aufruf mit 3 oder Parametern andere Dinge machst. Halte ich auch für unglücklich, weil aus der Semantik des Aufrufes nicht erkennbar ist, was passieren soll.
Betreffend Die Unabhängigkeit vom Busmaster: Nee, nicht ganz. DS9097 ist wirklich bei der Bus-Suche granatenmäßig schlechter als Interfaces mit echtem Busmaster.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 16 April 2014, 12:06:36
Halte ich auch für unglücklich, weil aus der Semantik des Aufrufes nicht erkennbar ist, was passieren soll.
Bin ich auch nicht wirklich glücklich drüber. Für konstruktive Vorschläge wie man das schöner bzw. verständlicher macht bin ich offen.
Zitat von: Prof. Dr. Peter Henning am 16 April 2014, 12:06:36
Betreffend Die Unabhängigkeit vom Busmaster: Nee, nicht ganz. DS9097 ist wirklich bei der Bus-Suche granatenmäßig schlechter als Interfaces mit echtem Busmaster.
muss mir wohl doch mal einen Löten, oder mag mir jemand einen sponsoren? Sonst rede ich hier wie ein Blinder von der Farbe ;-)
Gruß,
Norbert
Hallo Nornert,
schlag dir nen Deal vor. Du stellst mir ne Einkaufsliste und den Link zum Bauen eines (guten) aktiven Busmasters zusammen, gerne auch Links, und ich schick dir meinen DS9097 sobald ich das neue Ding angeschlossen habe.
Gruß Dan
Um so was wie diesen hier (http://www.fhemwiki.de/wiki/USB-Interface_f%C3%BCr_1-Wire) zu bauen brauchst Du:
so einen USB-FT232RL-Zu-Seriell-Adapter (http://www.ebay.de/itm/USB-FT232RL-Zu-Seriell-Adapter-USB-Auf-232-Kabel-Download-Modul-Arduino-Download-/121247006978?pt=DE_Computing_USB_Kabel_Hubs_Adapter&hash=item1c3ae28102) (oder diesen hier (http://www.ebay.de/itm/Neu-FT232RL-Download-USB-Kabel-Modul-Zu-Seriell-Adapter-USB-TTL-232-fur-Arduino-/111249933993?pt=DE_Computing_USB_Kabel_Hubs_Adapter&hash=item19e70346a9), bei dem kann man die Spannung per Schalter auf 3,3V ändern, bei ersterem nur per Lötbrücke).
Dann einen DS2480 (http://www.fuchs-shop.com/de/shop/5/1/13372164/). Zum Schutz vor Elektrostatik ist optional ein DS9503 (http://www.fuchs-shop.com/de/shop/5/1/13372206/) sinnvoll (siehe DS2480 Datenblatt (http://www.fuchs-shop.com/download/DS2480B.pdf), Kapitel 'HARDWARE APPLICATION EXAMPLES' ab Seite 24.)
Zur Stabilisierung der 5V-Versorgungsspannung 1x 22µF + 1x 100nF (siehe obrigen Schaltplan im FHEM-Wiki). Optional zum R/C-Filtern des 1-Wire-busses: 62 Ohm + 470pF (DS2480-Datenblatt ab Seite 24)
wenn Du keine Platine herstellen, sondern nur auf Lochraster verdraten willst, würde ich Dir zu SMD-Adaptern für SO-8 (http://www.ebay.de/itm/5x-SMD-Adapterplatine-SOIC-8-SO-8-SOP-8-Adapter-Raster-1-27mm-/151194593058?pt=Elektromechanische_Bauelemente&hash=item2333e66722) raten, mit so was habe ich gute Erfahrungen gemacht. (Das TSOC-gehäuse vom DS9503 läßt sich da auch drauflöten, da gehen nur die Pins unter das IC, nicht - wie bei SO-8 nach außen).
Bei mir funktioniert die Minimalbeschaltung aus dem FHEM-Wiki gut, die ESD-Schutzdioden sind primär sinnvoll, wenn man iButtons benutzen will (da liegen die Kontakte ja offen!).
Viel Erfolg,
Gruß,
Norbert
Die Frage ist, ob es nicht günstiger wäre, dieses hier (oder Ähnliches) zu kaufen:
http://www.ebay.de/itm/USB-1-wire-Adapter-mit-FT232RL-DS2480B-chipset-DS18S20-sensor-/171041719472?pt=Wissenschaftliche_Ger%C3%A4te&hash=item27d2e184b0
Und zum Thema "Einkaufsliste": http://www.fhemwiki.de/wiki/USB-Interface_f%C3%BCr_1-Wire
LG
pah
Also unabhängig davon ob ich nun einen Busmaster baue oder ihn fertig kaufe stellt sich mir noch die Frage, ob dann alles funktioniert. In einem Anderen Beitrag, durch den ich auf den Konflikt mit OWTHERM gekommen bin wurde mir auf die Frage, ob ein aktover Busmaster die Lösung ist, folgendes geantwortet:
ZitatJain,
wie im letzten Beitrag von mir schon geschrieben, gibt es einen grundsätzlichen Designfehler in den 1-Wire-Modulen, der FHEM auf jeden Fall ca.1200 msec blockiert. Damit muss man z.Z. bei 1-Wire leben, auch wenn hier Abhilfe in Arbeit ist.
http://forum.fhem.de/index.php/topic,13580.0.html
Das ist aber z.Z. noch experimentell, und kostet Hardwareperformance.
Diese Verzögerung kann man auch mit einem aktiven Busmaster nicht beseitigen, deshalb mein Vorschlag mit seperater FHEM Instanz, FHEM2FHEM und cloneDummy. Dafür habe ich den cloneDummy gebaut.
Das andere Problem ist wahrscheinlich Dein passiver Eigenbau Busmaster. Bei dem wird die "low level" Kommunikation durch FHEM/OWX resourssenverbrauchend auf Deiner Hardware gemacht, dabei muß Durch die Hardware die Kommunikation ("High und Low") auf dem Bus peinlich genau eingehalten werden. Wenn hier die Zeitschlitze nicht stimmen, funktioniert die Kommunikation mit den Sensoren nicht, es kommt zu Lesefehlern und die Zeit, in der FHEM blockiert wird verlängert sich. hier kann ein aktiver Busmaster helfen, da sich dieser dann selbst um die Kommunikation auf dem Bus kümmert, und die Hardware auf der FHEM läuft raus ist. Zusätzlich gibt es bei einigen aktiven Busmasten aktive pull up widerstände, die für eine bessere Flankensteilheit zwischen High und Low sorgen, und damit die Stabilität auf dem Bus erhöhen.
Was meint ihr als 1Wire-Spezialisten dazu?
ja, das ist so. Im Wesentlichen haben wir das hier im Thread auch nicht anders dargestellt.
Mit einem DS2480-Busmaster könntest Du OWX_ASYNC benutzen, das legt nicht pro Sensor und Messinterval die 1Sek. Wartepause ein. Ist bisher allerdings nur für Sensoren stabil. Aktoren funktionieren noch nicht so gut.
Allerdings verwahre ich mich dagegen, dass dies ein "Designfehler" ist - wer hat das denn geschrieben ?
Ohne das OWX-Backendmodul und die ganzen Frontendmodule wäre die 1-Wire-Ankopplung an FHEM echt in den Kinderschuhen.
Und das es gar nicht so trivial ist, das asynchron zu machen, merken wir derzeit.
LG
pah
Hallo pah,
Ich bin als Anwender schon recht lange mit Deinen OWX Modulen dabei und möchte hier mal auf die FHEM Statistik Seite verweisen. Wer hier meint, dass es nicht richtig läuft mit OWX sollte sich da mal die Zahl der installierten OWX, OWSWITCH, OWCOUNT etc. ansehen. Kaum zu glauben, das nur Deppen das einsetzten, die nicht merken wenn es nicht richtig läuft.
Bei mir im Produktiveinsatz mit 2 USB Adaptern DS2480 und weit über 20 Sensoren geht das jedenfalls sehr gut. Vielen Dank für die prima Modulentwicklung!
Daneben beobachte und teste ich natürlich auch gern die Weiterentwicklung in Richtung Async OWX.
ZitatAllerdings verwahre ich mich dagegen, dass dies ein "Designfehler" ist - wer hat das denn geschrieben ?
Ich war's, und es ist in Meinen Augen ein Designfehler.
In einem singlethreadet Programm, wie FHEM, in dem diverse Module betreut werden müssen, ist ein sleep (oder select(undef,undef,undef,3);) definitiv ein Designfehler. Das hat in einem singlethreadet Programm definitiv nichts zu suchen.
Lösungsweg 1:
komplette serielle Verarbeitung mit DevIO.pm und Freigabe der fhem-Schleife nach Schreiben in DevIO, wenn DevIO Daten meldet, Kontrolle und Verarbeitung.
Vorteil: FHEM wird nicht angehalten wie jetzt, ressourcenschonend
Nachteil: funktioniert nur bei aktivem Busmaster
Lösungsweg 2:
Auslagerung in seperaten Thread oder Programm
Vorteil: Es lassen sich auch passive Busmaster einbinden
Nachteil: Ressourcenhungrig, Anbindung deutlich komplizierter, Das Rad neu erfinden macht keinen Sinn, wenn OWFS das alles schon kann, und in C geschrieben ist.
Damit wir uns richtig verstehen, Modul läuft bei mir seit über einem Jahr wunderbar, solange keine weiteren Zeitkritischen Module in FHEM laufen. Es ist leider nicht zu gebrauchen, wenn HM oder andere ack-gesteuerte Module mit im Spiel sind
Gruß Joachim
@Joachim:
Erstens stimmt es nicht, dass das bei zeitkritischen Modulen nicht funktioniert: Ich habe sowohl Homematic-Devices, als auch OWX mit vier verschiedenen Busmastern im Einsatz. Mit einem aktiven Busmater beträgt die Blockade des Systems auch keine "1200 ms" - sondern gerade mal 100 ms, wenn nicht gerade eine Bussuche durchgeführt wird.
Zweitens ist es eben nicht möglich, die gesamte serielle Verarbeitung über DevIO zu machen - wie Norbert Truchsess gerade erneut bestätigt hat. Das kann man als Schwäche des gesamten 1-Wire-Systems ansehen - aber sicher nicht als Designfehler.
Ich bin selbst Theoretiker und habe immer Verständnis dafür, dass man aus grundlegenden theoretischen Überlegungen eine Realisierung kritisiert. Aber Theorien sind eben nicht beweisbar, sondern nur falsifizierbar - lies mal Deinen Popper nach. Und dann lass Dir sagen, dass die schöne Theorie, das alles über DevIO ganz einfach zu machen sei, eben falsifiziert worden ist.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 21 April 2014, 05:55:19
Zweitens ist es eben nicht möglich, die gesamte serielle Verarbeitung über DevIO zu machen - wie Norbert Truchsess gerade erneut bestätigt hat.
Das ist schon möglich, aber nur, wenn der aktive Busmaster das
gesammte Timing einer 1-Wire Befehlsfolge aus Reset/Adressierung/Daten selbstständig durchführen kann.
Die Busmaster-ICs DS2480/DS2482 können das nicht, da muss man mit dem nächsten Befehlsbyte warten, bis die jeweilige 1-Wire-Aktivität abgeschlossen ist. Wartet man á la DevIO asynchron (I have been there...), dann sind die Delays zwischen den Befehlen aber zu unbestimmt (und in der Regel zu lang). Das betrifft im wesentlichen die Länge des Reset-pulses - der Rest ist beim DS2480 unkritisch, da sorgt die Baudrate der seriellen Schnittstelle dafür, dass die nachfolgenden Befehlsbytes mit der richtigen Geschwindigket übermittelt werden. Beim DS2480 muss man also auch bei einer asynchronen Implementierung mit einer Blockade von FHEM in der Größenordnung von 70ms pro 1-Wire-Befehl leben.
100% über DevIO asynchron geht nur mit Einsatz eines µC auf Busmasterseite, wie z.B. bei der Arduino/FRM-Lösung.
Meine OWX_ASYNC-implementierung kann das aktuell schon soweit, dass die Reihenfolge und nötige Delays zwischen 1-Wire-Befehlssequenzen aus Reset/Addresse/Daten pro 1-Wire Device garantiert wird. Außerdem wird eine Bussuche asynchron iterativ durchgeführt (d.h. zwischen jedem gefundenen Device kommt FHEM wieder an die Reihe). Für 1-Wire-Sensoren funktioniert das Prima, Für 1-Wire-Aktoren ist das Desing aber (noch) fehlerhaft. Diese werden in der Regel in mehreren (voneinander abhängigen) Schritten beschrieben. Die Abhängigkeit ist da z.B. das Auslesen einer Prüfsumme nach Übermittlung der Daten und dem nachfolgenden Bestätigen dieser Prüfsumme. Es ist dabei wichtig, dass der betreffende 1-Wire-aktor keine anderen Kommandos dazwischen gesendet bekommt und das kann die aktuelle OWX_ASYNC-implementierung nicht garantieren, weil nicht alle Kommandos schon am Anfang der Abfolge gekannt sind.
Die nächste Evolutionsstufe ist aber schon in Arbeit :-)
Gruß,
Norbert
Leute, ob das ein Designfehler oder ein generelles 1wire Problem ist, ist doch zweitrangig. Ihr hört euch alle an als hättet ihr ne Menge Ahnung von der Materie und kennt alle das Problem. Versucht es doch gemeinsam zu lösen...
@ntruchsess: Da ich im Moment und in naher Zukunft nur meine 1wire Temperatursensoren abfragen möchte, könnte das doch meine Lösung sein, oder?
Allen noch schöne Ostern!
Zitat von: dan1180 am 21 April 2014, 14:08:46
@ntruchsess: Da ich im Moment und in naher Zukunft nur meine 1wire Temperatursensoren abfragen möchte, könnte das doch meine Lösung sein, oder?
Probier es doch einfach aus.
Moin pah,
nur um Missverständnissen vorzubeugen:
Ich finde Deine OWX-Module gut, und freue mich schon darauf, dass die asyncrone Variante vernünftig funktioniert.
Ich will auch nicht an den Modulen herummäkeln.
Allerdings bin ich immernoch der festen Überzeugung, dass es einen Designfehler in den Modulen gibt, und dass ist in meinen Augen konstruktive Kritik.
Übrigens tappt auch das OWDevice Modul in eine ähnliche Falle.
Nun zu Deiner Anwort:
ZitatErstens stimmt es nicht, dass das bei zeitkritischen Modulen nicht funktioniert
Dem ist leider nicht so, bedingt durch das aktive Warten des OWX-Moduls verliert HM definitiv die Verbindung, da es zu spät an die Reihe kommt, und dann den HM Lan nicht mehr rechtzeitig streicheln kann, was zu einem disconnect des HM Lan führt. Das passiert nicht jedes mal, und hängt von der Menge der 1-Wire Sensoren ab, ist aber anhand von Logs nachzuweisen. Da ich mein Produktivsystem deshalb jetzt nicht zerpflücke, kan ich Dir im moment nicht die Logs mitliefern, bin aber bereit, das nachzuholen.
ZitatMit einem aktiven Busmater beträgt die Blockade des Systems auch keine "1200 ms" - sondern gerade mal 100 ms, wenn nicht gerade eine Bussuche durchgeführt wird.
Da ich mit Deiner letzten OWX-Version arbeite, also wahrscheinleich die gleiche Version, die Du auch benutzt, widerspreche ich dir hier, 100ms sind ein Traumwert, der nicht eingehalten werden kann, wie man an dieser mit zusätzlichen Logeinträgen gewürzten OWTHERM Abfrage hervorragend erkennt (es ist jeweils vor und hinter select(undef,undef,undef ein Logeintrag):
Zitat17:59:09.225 3: Beginn OWXTHERM_GetValues
17:59:09.227 3: OWX: Sending out 0xe3 0xc5
17:59:09.227 3: Pause anfang
17:59:09.267 3: Pause ende # 40ms Pause
17:59:09.269 3: Pause anfang
17:59:09.289 3: Pause ende # 20ms Pause
17:59:09.289 3: OWX: Receiving in loop no. 1 0xdd
17:59:09.290 3: Pause anfang
17:59:09.300 3: Pause ende # 10ms Pause
17:59:09.302 3: OWX: Sending out 0xe1 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0x44
17:59:09.302 3: Pause anfang
17:59:09.343 3: Pause ende # 40ms Pause
17:59:09.344 3: Pause anfang
17:59:09.364 3: Pause ende # 20ms Pause
17:59:09.365 3: Pause anfang
17:59:09.375 3: Pause ende # 10ms Pause
17:59:09.375 3: OWX_Complex_SER: Receiving 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0x44
17:59:09.375 3: Beginn OWXTHERM_GetValues Pause anfang
17:59:10.176 3: Beginn OWXTHERM_GetValues Pause ende # 800ms Pause
17:59:10.178 3: OWX: Sending out 0xe3 0xc5
17:59:10.178 3: Pause anfang
17:59:10.218 3: Pause ende # 40ms Pause
17:59:10.220 3: Pause anfang
17:59:10.240 3: Pause ende # 20ms Pause
17:59:10.240 3: OWX: Receiving in loop no. 1 0xdd
17:59:10.240 3: Pause anfang
17:59:10.251 3: Pause ende # 10ms Pause
17:59:10.253 3: OWX: Sending out 0xe1 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
17:59:10.253 3: Pause anfang
17:59:10.293 3: Pause ende # 40ms Pause
17:59:10.295 3: Pause anfang
17:59:10.315 3: Pause ende # 20ms Pause
17:59:10.315 3: Pause anfang
17:59:10.326 3: Pause ende # 10ms Pause
17:59:10.326 3: OWX_Complex_SER: Receiving 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0xbe 0x50 0x01 0x4b 0x46 0x7f 0xff 0x10 0x10 0x49
17:59:10.326 3: Ende OWXTHERM_GetValues
# gesamt durch select(undef,undef,undef genutzte Zeit: 1080 ms Pause
Man sieht hier sehr gut, das FHEM für 1,08 Sekunden angehalten wird, und das ist inakzeptabel, wenn andere Zeitkritische Module zusätzlich in FHEM arbeiten. Wenn ich mich recht entsinne, muß ein ack in HM innerhalb von 60 bis 100 ms gesendet werden. Und das ist dann ein Designfehler, den man auf mehrere Arten lösen kann.
ZitatZweitens ist es eben nicht möglich, die gesamte serielle Verarbeitung über DevIO zu machen
hier hat Dir Norbert gerade widersprochen, und ich widerspreche hier auch, es ist allerdings nicht trivial das richtig zu programmieren. Wenn ich kein Perl-Anfänger wäre, und mehr Zeit hätte, würde ich es Dir auch gerne beweisen.
Zitatlies mal Deinen Popper nach
Wer ist das?
ZitatUnd dann lass Dir sagen, dass die schöne Theorie, das alles über DevIO ganz einfach zu machen sei, eben falsifiziert worden ist.
Bisher ist das noch nicht widerlegt worden.
Gruß Joachim
Hallo ntruchsess,
klar mache ich das, sofern die hier anweseden Profis einigermaßen gute Chancen für einen Erfolg einräumen. Ich möchte von niemandem Brief und Siegel nur wenn mir hier jemand sagt: "lass es, wird nicht besser", dann lass ich es. Ich verstehe die Aussagen zu meinem Problem so, dass ich mit einem aktiven Busmaster und dem asynchronen Modul meine 19 Sensoren abfragen können müsste, ohne meine HM Komponenten auszuhebeln?!?
Und noch eine Frage an alle:
Kann es sein, dass ich meinen DS9097 durch einen Reboot oder eine andere Aktion von FHEM kaputt gemacht habe? Über die Software digitemp werden all meine Sensoren erkannt. Ich kann jedoch keine Temoeraturen mehr abfragen. Auch eine Verbindung über OWX funktioniert nicht mehr "failed".
Danke, Dan
ZitatIch verstehe die Aussagen zu meinem Problem so, dass ich mit einem aktiven Busmaster und dem asynchronen Modul meine 19 Sensoren abfragen können müsste, ohne meine HM Komponenten auszuhebeln?!?
OWX_ASYNC ist noch in der Testphase, aber es sieht schon recht gut aus.
Ansonsten bleibt immer noch die Variante, die ich Die im anderen Tread geschrieben habe.
Gruß Joachim
Moin pah,
hat zwar etwas gedauert, bis ich Das Buch "Karl Popper Logik der Forschung" durch hatte, war sehr interessant.
hier mal ein unkommentiertes Zitat für Dich:
Zitat
Karl Popper Logik der Forschung 11. Auflage
II. Kapitel
Zum Problem der Methodenlehre
"Denn wer an einem System, und sei es noch so 'wissenschaftlich' dogmatisch festhält (z.B. an dem der klassischen Mechanik),
wer seine Aufgabe etwa darin sieht, ein System zu verteidigen, bis seine Unhaltbarkeit logisch zwingend bewiesen(bewiesen hervorgehoben, Anm. d. Verf.) ist,
der verfährt nicht als empirischer Forscher in unserem Sinn;
denn ein zwingender logischer Beweis für die Unhaltbarkeit eines Systems kann ja nie erbracht werden,
da man ja stets experimentelle Ergebnisse als nicht zuverlässig bezeichnen oder etwa behaupten kann,
der Widerspruch zwischen diesen und dem System sei nur ein scheinbarer und werde sich mit Hilfe neuer Einsichten beheben lassen...
Wer in den empirischen Wissenschaften strenge Beweise verlangt [oder strenge Widerlegungen],
wird nie durch Erfahrung eines Besseren belehrt werden können."
Gruß Joachim
Nicht doch. Möglicherweise solltest Du um 1:40 in der Frühe keine Mails mehr schreiben, da verwechselst Du dann Ursache und Wirkung. Zum Trost: passiert manchmal auch den Studenten, bei denen ich Wissenschaftstheorie lehre ...
Die Hypothese, dass das alles asynchron über DevIO laufen würde, stammt von Dir. Ich habe geschrieben: "Nein, das ist nicht so. Widerlegt durch ein Experiment". Norbert Truchsess widerspricht mir nicht, sondern sagt ganz eindeutig genau dasselbe: "Das geht nicht mit den DS2480 Busmastern".
Also ist nach Poppers (und meiner) Sicht derjenige, der an seinem System (in Popperschem Sinne) festhält: Joachim. Nicht pah ;D.
LG
pah
Joachim, Pah,
ich glaube Ihr redet einfach aneinander vorbei. Pah benutzt OWTHERM vermutlich mit 'doKick=1', Joachim vermutlich nicht. Deshalb gibt's bei Joachim auch die synchronen Pausen >= 1 Sek (mal Anzahl OWTHERM-devices). Bei Pah sind die nur 500ms lang (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/00_OWX.pm#L957) und treten nur einmal pro Kick-interval auf, das schmerzt rein statistisch natürlich viel weniger.
Diese Art von Pausen (längeres synchrones Warten per select) läßt sich mit asynchroner Verarbeitung über DevIO komplett vermeiden. Nicht vermeiden läßt sich, dass das Absenden einer 1-Wire-Kommandfolge mit einem DS2480 ca. 70-80ms Zeit braucht, auch wenn der Empfang der zugehörigen Daten asynchron über DevIO erfolgt.
Irgendwie passt das Poppers-zitat für Euch alle Beide, natürlich mit der jeweils eigenen Hypothese.
Hier übrigens die aktuelle asynchrone Implementierung dieser berüchtigten 1-Sekunden Pause basierend auf Protothreads (https://github.com/ntruchsess/fhem-mirror/blob/owx_async_protothreads/fhem/FHEM/21_OWTHERM.pm#L1116).
(Die eher sperrige API über OWX_Execute -> AfterExecuteFn ist damit obsolet geworden, jetzt läuft der Code nach der über DevIO empfangenen Antwort dort weiter, wo er beim Absenden des 1-Wire Befehls aufgehört hat).
Gruß,
Norbert
Nee, da lass ich auch nicht locker, das ist gegen meine Berufsehre: Ich habe keine Hypothese formuliert und halte an gar nichts fest.
LG
pah
Moin pah,
Ich bin immer wieder traurig, wenn ich mitansehen muss, wie gute Leute, die großartiges geleistet haben, sich irgendwann selbst demontieren.
Allerdigs bin ich auch erwachsen genug, um mich nicht wie einen dummen Jungen behandeln zu lassen.
Und solche Kommentare:
ZitatNicht doch. Möglicherweise solltest Du um 1:40 in der Frühe keine Mails mehr schreiben, da verwechselst Du dann Ursache und Wirkung. Zum Trost: passiert manchmal auch den Studenten, bei denen ich Wissenschaftstheorie lehre ...
kannst Du Dir sparen, denn sie tragen nicht zur Lösungsfindung bei.
Wenden wir uns jetzt doch mal den Fakten zu:
Du behauptest:
ZitatDie Hypothese, dass das alles asynchron über DevIO laufen würde, stammt von Dir.
Wenn Du meinen Beitrag gelesen hättest, wüsstest Du, dass ich das nie behauptet habe, meine Aussage war:
Zitatkomplette serielle Verarbeitung mit DevIO.pm und Freigabe der fhem-Schleife nach Schreiben in DevIO, wenn DevIO Daten meldet, Kontrolle und Verarbeitung.
asyncron != seriell
Du sprichst von:
ZitatWiderlegt durch ein Experiment
wo in diesem oder einem anderen Tread kann ich mir dieses Experiment ansehen?
Du behauptest:
ZitatMit einem aktiven Busmater beträgt die Blockade des Systems auch keine "1200 ms" - sondern gerade mal 100 ms,
Da Du dieses Modul geschrieben hast, gibt es nur die Erklärung, dass Du unter Annesie leidest (damit solltest Du zum Arzt gehen), denn die Alternative wäre, dass Du bewußt die Tatsachen verdreht hast, und das würdest Du als Wissenschaftler sicherlich nicht machen. Den Gegenbeweis zu Deiner Behauptung es dauert nur 100 ms habe ich hier vorgestern um 18:47 gepostet. Die Gesamtblockade von FHEM durch OWX/OWTHERM beträgt 1101 ms, davon 1080ms bedingt duch Blockieren der FHEM Hauptschleife, oder anders ausgedrückt, 98,09 % der Zeit werden damit verschwendet, dass FHEM schläft. Und dabei ist es egal, ob FHEM auf einem 386 DX 100 läuft, oder auf einem modernen Mehrkernprozessor.
Hier behaupte ich, das ist ein Designfehler, und habe 2 mögliche Lösungswege aufgezeigt.
Einer der beiden Lösungswege wird durch die asyncrone Implementierung von Norbert beschritten. Schon alleine damit wäre nach Popper, den übrigens Du ins Spiel gebracht hast, durch Falsifikation dargelegt, dass es diesen Designfehler gibt, denn sonst wäre es nicht nötig, Dein OWX-Modul umzubauen.
Der andere Lösungsweg wird von Dir mit:
ZitatZweitens ist es eben nicht möglich, die gesamte serielle Verarbeitung über DevIO zu machen
abgelehnt. Gerade als Wissenschaftler sollte Dir bewusst sein, dass diese Aussage so nicht haltbar ist.
Dass die Umsetzung nicht trivial ist, ist mir durchaus bewusst,da hier diverse Parameter zusammenspielen müssen, und man auf die Besonderheiten eines Singlethreadet Programms Rücksicht nehmen muss. Aber es ist nicht nur möglich, sondern, wenn es richtig programmiert ist, sogar machbar, die Conversions Pause dafür zu nutzen, weitere Sonsoren anzusprechen. Vorraussetzung dafür ist, dass folgende Sequenzen:
17:59:09.227 3: OWX: Sending out 0xe3 0xc5
17:59:09.289 3: OWX: Receiving in loop no. 1 0xdd
17:59:09.302 3: OWX: Sending out 0xe1 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0x44
17:59:09.375 3: OWX_Complex_SER: Receiving 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0x44
hier wären mindestens 800 ms Zeit, in denen man einen weiteren Sensor abfragen könnte oder z.B. eine weitere Conversion starten könnte.
17:59:10.178 3: OWX: Sending out 0xe3 0xc5
17:59:10.240 3: OWX: Receiving in loop no. 1 0xdd
17:59:10.253 3: OWX: Sending out 0xe1 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
17:59:10.326 3: OWX_Complex_SER: Receiving 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0xbe 0x50 0x01 0x4b 0x46 0x7f 0xff 0x10 0x10 0x49
nicht durch andere Sequenzen unterbrochen werden.
Sowohl nach dem Senden von
0xe3 0xc5 als auch nach dem Senden von
0xe1 0x55 0x28 0x46 0x38 0xba 0x03 0x00 0x00 0x0d 0xbe 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff und anderen
kann der Ablauf wieder an die FHEM-Hauptschleife abgegeben werden, da DevIO selbsttätig die Empfangenen Daten an OWX liefert, wenn in OWX_Initialze ein
$hash->{ReadFn} definiert ist. In OWX muss das ganze dann nur noch aufbereitet, auf Plausiblität überprüft und an den richigen Empfänger weitergeleitet werden.
Selbst, wenn man nur die 800 ms Pause entfernen würde, wären dass statt 98,09 % nur noch 25,43 % "sleep-Zeit" also eine signifikante Verbesserung.
Ich weiß, dass ich den Beweis nur dann endgültig ( und nach Popper nicht mal dass) erbringen kann, wenn ich Dir ein Modul schreibe, dass genau das leistet. Aber dazu fehlen mir z.Z. noch die Perl Kenntnisse, außerdem würde ich Dich dann komplett demontieren, was ich nicht wirklich möchte.
Es würde mir volkommen reichen, wenn Du über Deinen Schatten springst, und einräumst, dass hier ein Designproblem (nicht Fehler) vorhanden ist, welches Du so heute nicht mehr machen würdest.
Ich appelliere hier mal an Deine Berufsehre als Naturwissenschaftler, denn wir wissen alle, die Erde ist keine Scheibe, oder in anderen Worten: ,,Eppur si muove"
Gruß Joachim
@ Norbert,
habe mir Deine asyncrone Variante schon mal kurz angesehen, sieht gut aus. Wenn ich dann wieder mehr Zeit habe, teste ich nocheinmal ausführlicher.
Ich glaube auch nicht, dass wir, pah und ich, aneinander vorbeireden, es will nur keiner nachgeben ;D
@ dan1180,
sorry, dass wir Deinen Tread gekapert haben, aber ich befürchte, dass wird hier noch etwas dauern, von daher für Dich der Anhang.
@Joachim: Drei Vorschläge.
Fangen wir doch mal hinten an: Bitte, gerne, schreibe ein Frontendmodul, das alles besser macht. Da ich weder mein Selbstbewusstsein, noch meine Identität aus ein paar FHEM-Modulen ziehe, "demontiert" mich das sicher nicht. Das kann auch nicht an Perl-Kenntnissen liegen - wenn man eine Programmiersprache kann, geht das auch mit anderen innerhalb kürzester Zeit - also, nur zu ! Und bitte sieh dies nicht als Sarkasmus, sondern als ernsthafte Ermunterung. Erster Vorschlag also: "Designe" selbst, und lass die offensive Sprechweise vom "Demontieren" sein.
Zweitens: OWX ist das Backendmodul, das kennt, wenn man nicht gerade den etwas kryptischen DoKick-Mechanismus verwendet, gar keine Warteschleifen (die übrigens alle nicht mit sleep, sondern mit select realisiert sind). Du kannst dich also höchstens auf eines der Frontendmodule beziehen - z.B. OWTHERM. Dieses Modul hat keinen "Designfehler", Punkt. Dass darin eine Verzögerung auftritt, wenn man einen Sensor direkt abfragt, war 2011 vollständig gewollt. Will man diese herausnehmen, muss aber eine komplette Warteschlange für den 1-Wire-Bus geschrieben werden, da eine vollständig asynchrone Behandlung sonst zur Kollision mit anderen Busbefehlen führen würde. Das genau ist, was Norbert Truchsess gerade gemacht hat.
Es ist unbenommen, dass die Vielzahl von neuen Modulen und gestiegene Anforderungen an FHEM die asynchrone Verarbeitung sinnvoll machen. Das macht die alten Versionen aber nicht "fehlerhaft". Ein kurzer Check zeigt vielmehr, dass "select"-Befehle noch in einer Vielzahl von Modulen auftauchen, die auch breite Verwendung finden - und die sind sicher auch nicht "fehlerhaft". Zweiter Vorschlag also: lass einfach die offensive und herabsetzende Wortwahl vom "Designfehler" weg. Von mir aus sprich von "veraltet" - damit kann jeder gut leben.
Schließlich: Ich freue mich ehrllich, wenn jemand innerhalb von zwei Tagen von "Popper - wer ist das ?" dazu übergeht, Popper zu zitieren. Allerdings glaube ich, dass da noch ein paar Missverständnisse vorliegen - nicht zwischen uns beiden, sondern zwischen Deinem Verständnis von Popper und dem, was die akademische Welt darüber denkt. Ich halte allerdings einerseits dieses Forum nicht für den geeigneten Platz für eine Diskussion über Wissenschaftstheorie. Und andererseits: Hätte ich selbst gerade mal ein Werk dazu gelesen, würde ich in eine solche Diskussion nicht einsteigen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 23 April 2014, 07:21:53
keine Warteschleifen (die übrigens alle nicht mit sleep, sondern mit select realisiert sind).
Nur mal ne kurze Anmerkung für alle Mitleser: der Unterschied zwischen einem sleep(x) und einem select(undef,undef,undef,xxx) ist die zeitliche Auflösung. Beide halten den aktuellen Thread einfach an.
Moin pah,
wir nähern uns an, das finde ich gut. Ich möcht hier dann auch nocheinmal betonen, dass ich weder Dich persönlich angreifen wollte, noch Dein Modul schlecht machen will.
Dein Modul läuft bei mir seit über einem Jahr, allerdings mt der Einschränkung, dass es Probleme gibt, wenn andere Module im Spiel sind, die zeitkritisch sind. Deshalb ist z.B. das Modul cloneDummy entstanden, und OWX in einer seperaten Instanz laufen zu lassen, dort macht es fast nichts aus, dass FHEM regelmäßig schläft, es sei denn, dass genau zu diesem Zeitpunkt FHEM2FHEM über telnet Daten abgreifen will, da findet dann auch wider eine Verzögerung eines eigentliche unbeteiligten FHEM durch den Designfehler in de OW-Modulen statt.
Jetzt zu Deinem letzten Post:
ZitatZweiter Vorschlag also: lass einfach die offensive und herabsetzende Wortwahl vom "Designfehler" weg.
Ich habe ganz bewußt den Begriff "Designfehler", und nicht Fehler (Bug) verwendet. Denn Dein Programm ansich ist nicht fehlerhaft!
Ich sehe in der Wortwahl "Designfehler" auch keine offensive oder herabsetzende Wortwahl. Sollte das bei Dir so angekommen sein, entschuldige ich mich dafür.
Für mich ist ein "Designfehler" ein Fehler im Grundkonzept der Software (Deines Moduls), der unter bestimmten Bedingungen Nebenwirkungen zeigt, die so nicht gewünscht sind, oder die zum Zeitpunkt der Erstellung des Moduls so nicht absehbar waren, und zu einem späteren Zeitpunkt nur sehr aufwendig zu ändern sind.
Hier stimmst Du mir ja auch zu:
ZitatDass darin eine Verzögerung auftritt, wenn man einen Sensor direkt abfragt, war 2011 vollständig gewollt.
Daran war 2011 auch nichts auszusetzen, da es hier diese Probleme noch nicht gab. Mittlerweile sind wir im Jahr 2014 und es gibt viele neue Module, die auf ein einigemaßen genaues Timing angewiesen sind, oder die in festgelegten Abständen gestrichelt werden wollen. Und jetzt zeigt sich, das das Design, das Du 2011 gewählt hast, mit diesen Anfordungen nicht mehr mithalten kann, und das ist, ohne Deine Module abwerten zu wollen, ein Fehler im Design, der sich jetzt in schwer nachvollziehbaren Problen zeigt. Deshalb ist z.B. dieser Tread von dan1180 überhaupt erst entstanden, und vorher in einem ganz anderen Forum diskutiert worden:
http://forum.fhem.de/index.php/topic,22223.0.html Antwort 34 von Martin876
und es hat sehr lange gedauert, bis der Verursacher OWX ausgemacht wurde.
Ein Blick in den Quellcode Deines Moduls zeigt dann auch, wodurch das Problem ausgelöst wird.
Hier verweise ich dann auch nochmal auf die von mir in diesem Tread desöfteren gemachten Aussagen und Versuche.
Exemplarisch an der Kombination OWTHERM in Verbindung mit OWX und einer einfachen Temperaturabfrage eines DS18B20 sieht man, dass von 100 % Rechenzeit gerade mal 2 % verwendet werden, und 98 % verwendet werden, um FHEM anzuhalten (select(undef,undef,undef,xxx), ich gebe zu, dass ich heute morgen aus Faulheit "sleep-Zeit" geschrieben habe, das war sicherlich wissenschaftlich nicht korrekt, aber deshalb auch bewußt in "".
Für mich ist allerdings Deine Behauptung:
ZitatZweitens: OWX ist das Backendmodul, das kennt, wenn man nicht gerade den etwas kryptischen DoKick-Mechanismus verwendet, gar keine Warteschleifen (die übrigens alle nicht mit sleep, sondern mit select realisiert sind).
nicht nachvollziebar, wie einfach am Quellcode zu zeigen ist:
sub OWX_Query_2480 ($$$) {
my ($hash,$cmd,$retlen) = @_;
my ($i,$j,$k,$l,$m,$n);
my $string_in = "";
my $string_part;
#-- get hardware device
my $owx_hwdevice = $hash->{HWDEVICE};
$owx_hwdevice->baudrate($owx_baud);
$owx_hwdevice->write_settings;
if( $owx_debug > 2){
my $res = "OWX: Sending out ";
for($i=0;$i<length($cmd);$i++){
$j=int(ord(substr($cmd,$i,1))/16);
$k=ord(substr($cmd,$i,1))%16;
$res.=sprintf "0x%1x%1x ",$j,$k;
}
Log 3, $res;
}
my $count_out = $owx_hwdevice->write($cmd);
if( !($count_out)){
Log 3,"OWX_Query_2480: No return value after writing" if( $owx_debug > 0);
} else {
Log 3, "OWX_Query_2480: Write incomplete $count_out ne ".(length($cmd))."" if ( ($count_out != length($cmd)) & ($owx_debug > 0));
}
#-- sleeping for some time <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
select(undef,undef,undef,0.04);<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
#-- read the data - looping for slow devices suggested by Joachim Herold
$n=0;
for($l=0;$l<$retlen;$l+=$m) {
my ($count_in, $string_part) = $owx_hwdevice->read(48);
$string_in .= $string_part;
$m = $count_in;
$n++;
if( $owx_debug > 2){
Log 3, "Schleifendurchlauf $n";
}
if ($n > 100) {
$m = $retlen;
}
select(undef,undef,undef,0.02);<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
if( $owx_debug > 2){
my $res = "OWX: Receiving in loop no. $n ";
for($i=0;$i<$count_in;$i++){
$j=int(ord(substr($string_part,$i,1))/16);
$k=ord(substr($string_part,$i,1))%16;
$res.=sprintf "0x%1x%1x ",$j,$k;
}
Log 3, $res
if( $count_in > 0);
}
}
#-- sleeping for some time<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
select(undef,undef,undef,0.01);<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
return($string_in);
}Ich hoffe, Du hast Verständniss dafür, dass ich mich hier, vorsichtig gesagt, auf den Arm genommen fühle, denn das sind eindeutig Warteschleifen!
Die Du allerdings 2011 so für nötig erachtet hast, und die 2011 keine Probleme verurscht haben.
Deine Behauptung:
ZitatDieses Modul hat keinen "Designfehler", Punkt. Dass darin eine Verzögerung auftritt, wenn man einen Sensor direkt abfragt, war 2011 vollständig gewollt.
ist leider ein Widerspruch in sich. Es war vom Design her 2011 von Dir so gewollt, Du hast Dich also 2011 ganz bewußt für diesen Weg entschieden, der sich jetzt, 2014, als "ungeschickt" herausstellt. Man könnte auch sagen, im nachhinein betrachtet war es ein Designfehler, den Du heute so nicht mehr machen würdest.
Zu Deinem Vorschlag:
ZitatFangen wir doch mal hinten an: Bitte, gerne, schreibe ein Frontendmodul, das alles besser macht. Da ich weder mein Selbstbewusstsein, noch meine Identität aus ein paar FHEM-Modulen ziehe, "demontiert" mich das sicher nicht. Das kann auch nicht an Perl-Kenntnissen liegen - wenn man eine Programmiersprache kann, geht das auch mit anderen innerhalb kürzester Zeit - also, nur zu ! Und bitte sieh dies nicht als Sarkasmus, sondern als ernsthafte Ermunterung. Erster Vorschlag also: "Designe" selbst, und lass die offensive Sprechweise vom "Demontieren" sein.
Meine Programmierkenntnisse stammen aus dem Jahr 1984, Informatikgrundkurs in der Schule auf Apple 2 mit Basic, ich habe weder einen akademischen Abschluss, noch eine Ausbildung im Bereich Elektrotechnik, Elektronik, Informatik o.ä., sondern arbeite im Gesundheitswesen. Damit behaupte ich, das meine Programmierkenntnisse gen 0 tendieren.
Gerne würde ich ein entsprechendes Modul schreiben, wenn ich es dann könnte, und ich verstehe das auch nicht als Sarkasmus, denn ich weiß, das schöne an open source ist, dass man Dinge, die einem nicht gefallen verändern kann.
Ansonsten, Danke für die Blumen:
ZitatSchließlich: Ich freue mich ehrllich, wenn jemand innerhalb von zwei Tagen von "Popper - wer ist das ?" dazu übergeht, Popper zu zitieren.
ZitatUnd andererseits: Hätte ich selbst gerade mal ein Werk dazu gelesen, würde ich in eine solche Diskussion nicht einsteigen.
Gruß Joachim
PS.:Dieses select (Zeile 1541ff) ist übrigens vollkommen unnötig, da zu diesem Zeitpunkt schon alle Daten vom DS2480 angekommen sind:
#-- sleeping for some time
select(undef,undef,undef,0.01);
return($string_in);
}
weil es hier so gut passt, Someone is wrong on the internet (https://xkcd.com/386/) ;)
Moin Norbert,
mein Englisch ist leider grottenschlecht, von daher weiß ich nicht, ob ich das jetzt richtig verstanden habe.
Meinst Du, dass ich zu grob mit pah umgehe?
Gruß Joachim
nein, eigentlich wollte ich nur das Bild verlinken, der Text passt nicht. Hab grade das Original wiedergefunden (und meinen Post korrigiert)....
Einfach mal einen Schritt zurücktreten und sich vom 'SIWOTI syndrome (http://rationalwiki.org/wiki/Xkcd)' befreien...
(Und auch diesen Post nicht zu ernst nehmen).
Gruß,
Norbert
Norbert,
ich fühle mich wie Rudi Carrell, der hat allergings deutsche Wortspiele nicht verstanden.
Nun, wenn ich um 1:40 in der Frühe eine Mail von Joachim bekomme mit einem Zitat von Karl Popper, fühle ich mich schon sehr an http://rationalwiki.org/wiki/File:Xkcd_comic_386.png erinnert...
Zum Thema OWX und Schleifen: Richtig, stimmt, die kleinen Schleifen mit ein paar ms sind drin - an die hatte ich nicht mehr gedacht. Diese sind aber zeitkritisch bei der Ansteuerung des DS2480, und durch viel Ausprobieren entstanden. Übrigens auch das abschließende 10ms lange Segment...
Ich hatte die langen Wartezeiten vor Augen, über die sich hier mehrere Leute beschwert haben.
Betreffend die Semantik: Ich habe keine Lust, seitenlange Episteln über die Semantik des Wortes "Fehler" zu schreiben. Dennoch, den Begriff "Designfehler" lehne ich nach wie vor ab und finde ihn tatsächlich offensiv und herabsetzend. Ich schreibe niemandem vor, welche Worte er zu verwenden hat - also such es Dir aus, ob Du das als notwendig erachtest. Vor allem, wenn Du Deine eigenen Programmierkenntnisse auf 1984 datierst.
LG
pah
Moin pah,
ich bin erschüttert, ich hatte mich schon so auf eine sachliche Diskussion mit einem hochintelligenten Gegenüber gefreut.
Schade ansich,denn genau solche Diskussionen bringen die Wissenschaft voran.
Jetzt wirkt es so, als ob Du kneifen möchtest, da Dir
a) diese Diskussion lästig wird
oder
b) Du glaubst in dieser Diskussion zu unterliegen, da Du zugeben musst, das ich recht habe.
Dein Verhalten erinnert mich sehr an die allseits bekannte Salami-Taktik, Behauptungen aufstellen, und dann scheibchenweise nur das zugeben, was nicht mehr zu leugnen ist und sich dabei auf Gedächnisslücken zu berufen. Da hätte ich mehr von Dir erwartet.
Wahrscheinlich habe ich Popper dann doch besser verstanden wie erwünscht.
Es ist schon traurig, wenn Dir nichts besseres mehr einfällt, als zum widerholten Male auf der Uhrzeit 1:40 herumzureiten.
Was die lange Wartezeit von 800 ms in OWTHERM angeht, da kann ich nur sagen, die ist indiskutabel in einem SingleThreadet Programm wie FHEM, aber warum sollte ich in der Diskussion gleich mit den Brüllern kommen, wenn es doch auch noch die Kleinigkeiten gibt. Ich hatte doch schon geschrieben, dass ich dich nicht demontieren will, das machst Du ja von ganz alleine, da benötigst Du meine Mithilfe nicht.
Betreffen der Wortwahl "Designfehler": Ich habe mir das nicht ausgedacht, sondern Nachgelesen, wie dieser Fehler zu benennen ist, die Definition ist also nicht von mir, und mehr als darauf hinweisen, dass
ZitatIch sehe in der Wortwahl "Designfehler" auch keine offensive oder herabsetzende Wortwahl. Sollte das bei Dir so angekommen sein, entschuldige ich mich dafür.
kann ich nicht.
Hier mal einigeLinks:
http://www.elg-halle.de/fachschaften/informatik/Klassen/11/Fehlerarten%20Debuggen.pdf
http://wiki.infowiss.net/Designfehler
http://de.wikipedia.org/wiki/Programmfehler#Klassifizierung_von_Fehlern
Und komm mal von Deinem hohen Ross herunter, nur weil ich Programmierkenntnisse von 1984 habe, heißt das noch lange nicht, das mir der logische Menschenverstand und das analytische Denken fehlt, nein, im Gegensatz zu Dir bin ich mir durchaus bewusst, das ich weiß, das ich nichts weiß.
Oder um es in Poppers Worten zu sagen:
Zitat,,Wie Sokrates weiß der Stückwerk-Ingenieur, wie wenig er weiß. Er weiß, dass wir nur aus unseren Fehlern lernen können. Daher wird er nur Schritt für Schritt vorgehen und die erwarteten Resultate stets sorgfältig mit den erreichten vergleichen..."
Vgl. Karl Popper, Das Elend des Historizismus, Tübingen 1965, S. 53 f.
Zusammenfassen bleibt zu Sagen:
Es gibt einen grundlegenden Designfehler in den OW-Modulen.
Du bist nicht halb so intelligent, wie ich gedacht habe.
Du stellst unwahre Behauptungen auf, und berufst dich nachträglich auf Gedächnislücken.
Und Deine Berufsehre war auch nur vorgeschoben.
Um den Tread von dan1180 nicht weiter zu kapern, sollten wir es dann hier beenden, der geneigte Leser mag sich selbst ein Bild machen.
Gruß Joachim
Nun, wer es nötig hat, Aussagen über die Intelligenz anderer Leute zu treffen, soll das eben tun. Ist damit für mich erledigt.
pah
Hallo Leute,
also ich war jetzt ein paar Tage weg und bin mittelmäßig erschüttert, was aus meiner Hilfesuche geworden ist. Wenn ich die Programmschnipsel mal ausblende, die ich leider (noch) nicht verstehe, kann ich aus euren Beiträgen folgendes lesen:
Das Modul OWTHWERM kommt mit den aktuellen Anforderungen in FHEM, ins Besondere mit zeitkritisch kommunizierenden Komponenten, wie z.B. HomeMatic, nicht klar. Ob ihr das jetzt "Designfehler", "Fehler" oder "veraltet" nennt ist - mir zumindest - ziemlich egal. Kann ich für mich abspeichern, dass OWTHERN das nicht in der benötigten Kürze kann?
Pah ist durchaus bewusst, dass dieses Problem besteht, wehrt sich jedoch gegen den Begriff "Designfehler"? Sollte dem so sein wäre mir zur Lösung (nicht nur meines) Problems sehr recht, wenn wir uns vielleicht auf einen allseits genehmen Begriff einigen könnten (nennen wir es doch ein "veraltetes Design"). Damit würden wir die Möglichkeit schaffen, dass die Personen das Problem lösen können denen ich jetzt einfach mal die fachliche Kompetenz zuspreche.
Joachim scheint ein klasse Analyst ohne Programmierkenntnisse zu sein (ist jetzt wirklich anerkennend gemeint). Durch seine Fragen und Analysen konnte, zumindest in meinem System, die Verzögerung in OWTHERM als Ursache für meine HomeMatic Aussetzer gefunden werden. Wenn doch die veralteten Programmzeilen durch ihn analysiert wurden, warum setzten wir (besser gesagt ihr, die das könnt) da nicht an und baut dieses Modul um?
ntruchsess ist ein scheinheiliger Mensch, der mir vor der Nase den letzten verfügbaren 1wire Bus wegkauft und mir dann hier den Tip gibt mal nachzufragen, ob denn noch einer verfügbar sei ;D Aber keine Angst...ich kann wohl noch einen aus einer neuen Charche bekommen. Vielen Dank für den Hinweis! Und danke für den Versuch diesen Beitrag wieder in eine sachliche Diskussion zu verwandeln. Auch wenn der Erfolg noch auf sich warten lässt.
Alle zusammen könnt ihr euch vielleicht, wie schon gaaanz am Anfang mal erwähnt, auf das eigentliche Problem stürzen, ohne euch all zu viele Gedanken über die Benennung des Selben zu machen. Denn der Sinn dieses Beitrags war ursrünglich mein Anliegen 1wire und HomeMatic stabil mit einer FHEM Installation zu betreiben. Ich weiß, das ist lange her. Deshalb diese Erinnerung. Ich bin jetzt einfach mal so egoistisch auf MEIN PROBLEM zurück kommen zu wollen denn ich vermute, dass es am Ende doch der Allgemeinheit zuguten kommt.
Und zu guter letzt auch von mir noch ein Zitat:
ZitatWarum passieren mir immer Sachen, die sonst nur dämlichen Menschen passieren?
Homer
Moin Dan 1180,
Ich hatte mich ja schon für das Kapern Deines Threades entschuldigt, ich hoffe, das Popcorn war gut.
Nun zu Deinem eigentlichen Thread:
Es sind hier mehrere Lösungen am werden, allerdings alle noch in der Erprobung.
Variante 1, siehe hier:
http://forum.fhem.de/index.php/topic,13580.0.html
Sieht schon recht gut aus, aber noch in der Versuchsphase, Stabilität für ein Produktivsystem kann noch nicht garantiert werden.
Beruht auf den bekannten, guten und stabilen OWX-Modulen von pah, und umgeht den "Designfehler" durch Auslagern in Protothreads
Variante 2, siehe hier:
http://forum.fhem.de/index.php/topic,16945.0.html
Sieht ebenfalls schon recht gut aus, ist aber auch definitiv noch "beta". Es ist eine Kombination von OWFS als soliden Unterbau und einer Anbindung über OWServer/OWDevice an FHEM, es ist ebenfalls eine Weiterentwicklung, da die ursprüngliche OWServer/OWDevice einen vergleichbaren "Designfehler" hatte.
Variante 3, das FHEM mit 1-Wire als seperaten Prozess entweder auf der selben Hardware, oder einer abgesetzten Hardware laufen lassen, mittels FHEM2FHEM und cloneDevice die Sensoren auf das Hauptsystem clonen.
Variante 3, 1-Wire (mit OWX) mit einem LinkUSBi oder dem Kristech-Adapter auf der FB7390 läuft bei mir in Verbindung mit Max-Cube und HM-LAN auf dem Hauptsystem, Raspberry Pi, zufriedenstellend.
Für welche Variante Du Dich letztendlich entscheidest, kannst nur Du selber sagen.
Solltest Du noch weiter Fragen haben, melde Dich einfach wieder.
Gruß Joachim
@dan1180: Es ist kein Designfehler - weder in OWX, noch in OWServer. Da sollte man vielleicht auch bei der Beurteilung lieber den Leuten vertrauen, die die Sachen entwickeln - und nicht denjenigen, die anderen die Intelligenz absprechen.
Bei vielen Nutzern laufen OWTHERM-Module zusammen mit anderen, auch zeitkritischen FHEM-Subsystemen. Eine Modifikation in Richtung auf eine asynchrone Abfrage ist alles andere als einfach, seit mehr als einem Jahr sitzen wir (vorwiegend Norbert Truchsess) da dran.
LG
pah
Zitat von: dan1180 am 24 April 2014, 22:22:57
... vor der Nase den letzten verfügbaren 1wire Bus wegkauft ... oh weh, der letze Bus fuhr ohne Dich ab. Ich hätte da noch einige Meter WLAN Kabel günstig anzubieten!
Lies bitte einfach noch mal meinen Beitrag weiter unten, ich habe auch die Heizkörper komplett über Homematic geregelt und schon sehr lange (direkt nach dem pah die OWX Module hier im alten Forum veröffentlicht hat) über 2 Dutzend 1-wire Devices im Dauereinsatz. OK, letzten September bin ich vom RPI auf Cubieboard2 umgestiegen, da FHEMWEB sterbend langsam reagierte und vorher von FB7390 auf RPI. Aber das hat eher mit der gewachsenen Größe meiner Haussteuerung an sich zu tun. Bei derzeit 1660 Zeilen in der fhem.cfg musste die Serverhardware eben ab und an mal was beschleunigt werden.
Ich teste aktuell die asynchronen Bemühungen von Norbert auf einem extra System. Das scheint wirklich schwierig zu sein, bei jedem Release geht was anderes nicht wie gewünscht. Da sollten wir Nichtprogrammierer mMn. schön ruhig sein, testen und abwarten bis es am Ende sicher geht.
@det. Guter Ansatz - aber wo bitte hast Du das Zitat mit dem WLAN-Kabel her ?
LG
pah
Hallo,
@det:
Außer deinem Lob an pah finde ich nur den Beitrag mit der Spannungsversorgung der Sensoren. Ich habe darauf geantwortet, dass mein BUS mit Spannungsversorgung ist, dies nur in FHEM nicht eingeschaltet/bekanntgegeben wurde. Seit ich das kurzzeitig umgestellt hatte tut mein 1wire gar nicht mehr. Wie ebenfalls geschreiben aber wahrscheinlich in dem "Gezanke" ;D untergegangen, habe ich die Frage gestellt, ob es da einen Zusammenhang geben kann. Digitemp (ist das bekannt? http://www.kompf.de/weather/pionewire.html) findet meine Sensoren alle, gibt jedoch keine Temperaturen aus. FHEM failed schon beim Verbinden von OWio1. Neuer BUS ist, wie ebenfalls beschreiben, in Beschaffung.
@pah:
Bitte versteh, dass es mir reichlich egal ist ob es sich um einen Designfehler handelt oder nicht. Ich hätte eine solch kindische (damit mein ich alle beteiligten) Diskussion hier nicht erwartet. Wenn doch so viele die Kombination aus HomeMatic und OWTHERM verwenden, warum kann mir dann niemand sagen was ich tun muss damit es funktioniert? Meine Probleme, die zu diesem Beitrag geführt haben, könnt ihr alle unter http://forum.fhem.de/index.php/topic,22223.msg159096.html#msg159096 nachlesen.
@Joachim:
Auch wenn ich deinen Teil der Diskussion nicht weniger kindisch finde als den von pah; danke für die bisherige Hilfe. Ich werde mir, sofern nicht bessere Lösungen von denen kommen die das alles "ohne Probleme seit Jahren" betreiben die genannten Ansätze mal anschauen. Die zweite FHEM Installation schließe ich eher aus, da wohl trotzdem in einem gaaanz dummen Fall (wie von dir etwas vorher beschrieben) auch hier ein Konflikt auftreten kann.
Weitere SACHDIENLICHE Beiträge sind gerne erwünscht!
...und dafür schon einmal vielen Dank ;)
Zitat von: Prof. Dr. Peter Henning am 25 April 2014, 19:20:10
@det. Guter Ansatz - aber wo bitte hast Du das Zitat mit dem WLAN-Kabel her ?
LG
pah
Hallo pah,
Das "Zitat" gehörte außerhalb der "Zitatbox" als bosnickliche Anmerkung von mir. Die Forensoftware bedient sich gruselig vom IPad aus.
@det: Den hier meinst Du ? http://www.legacy.com/obituaries/pressconnects/obituary.aspx?pid=169499088
LG
pah
So, ein Problem scheint gelöst zu sein. Mein 1wire BUS wurde nicht mehr gefunden, weil meine 00_OWX.pm wohl bei einem Update überschrieben wurde. Hier war mein DS9097 manuell eingetragen.
FHEM ist nun leider wieder sterbens langsam... :'( Werd deshalb jetzt mal das mit dem ASYNC testen. Drückt mir die Daumen!
@dan,
Asynchron ging schon mal richtig super, wenn Du nur Thermometer Sensoren dran hast - aber nimm nicht die letzte Version hier aus dem Beitrag, da aktualisierten sich genau die Thermometer nicht - dafür schalten die Switch. Ist wie schon geschrieben nicht so einfach.
Norbert wird da aber bestimmt dranbleiben, vielleicht wartest Du noch bis die nächste Version wieder die Temperaturen regelmäßig aktualisiert. Ich habe produktiv alle möglichen Devices pro 1wire Bus durcheinander - leider, so warte ich bis ASYNC für alle funktioniert.
Hallo det,
zu spät :-\
Ich glaub aber ich weiß was du meinst...Ich hab vor 25 Min fhem WEB aufgerufen und das dauert immernoch. Werd den ganzen Ordner "FHEM", den ich glücklicherweise gesichert habe, wieder überschreiben und auf Standard zurückk gehen. Bringt es eigentlich was, wenn ich mein Abfrageintervall größer stelle?
...So, jetzt ist alles wieder beim Alten...LEIDER! Was mir noch eingefallen ist: Ihr sagt, dass ihr 1wire mit HomeMatic im Einsatz habt und keine Probleme. Hat von euch jemand einen HM-CC-VD im Einsatz? Der war nämlich das ursprüngliche Problem. Da FHEM durch die Blockadezeit von 1wire eine Abfrage des Stellantriebs verpasst hat ging dieser ständig in Notbetrieb (Ventilposition 15%).
Naja und das FHEM-WEB mit OWTHERM ar...langsam ist ist mir jetzt erst wieder bewusst geworden da ich meinen OWX ein paar Tage deaktiviert hatte.
Erstens stellt sich die Frage, warum DS9097 irgendwo in 00_OWX.pm "manuell eingetragen" war.
Zweitens: Verzögerungen im Bereich von 25 Minuten haben nichts mit den Abfrageintervallen von OWX zu tun - sondern deuten auf einen Fehler in der Konfiguration oder bei der Hardware.
Drittens: Man kann einen DS9097 mit dem ASYNC-Modul beliebig lange testen. Da er davon bisher nicht unterstützt wird, ist das aber nicht sehr erfolgversprechend. Bessere Lösung: Anständiges Interface kaufen für 20 €.
pah
Zu Erstens habe ich keine Ahnung. Mein DS9097 wurde nicht erkannt und musste deshalb FHEM vorgestellt werden (http://forum.fhem.de/index.php/topic,17684.msg117110.html#msg117110). Kann schon da die Ursache liegen, dass die Zeiten übermäßig lange sind und deshalb HM aussteigt?
Zweitens habe ich so nie behauptet! Bitte nicht in allem einen Angriff auf OWX sehen. Nichts läge mir ferner als mit meinem Kenntnisstand Module zu kritisieren. Verursacher war wohl ein Fehler bei der manuellen Installation der Asynchron Module oder die Tatsache, wie det geschrieben hat, dass die im Moment nicht funktionieren. Whatever...nachdem ich meinen alten FHEM Ordner wieder drübergespielt habe hab ich wieder die alten Verzögerungen < 2Min.
An Drittens bin ich dran.
Hallo dan1180,
Ich habe von Homematic nur diese neuen Heizkörper Stellventile und Fensterkontakte im Einsatz. Hier im Forum hat mal ein kluger Mensch diesen Link gepostet [size=78%]https://blog.chanoa.de/category/heimautomatisierung/fhem-performance (https://blog.chanoa.de/category/heimautomatisierung/fhem-performance)[/size]
Setz mal so viel wie möglich von den Vorschlägen dort um, bei mir hat das prima geholfen.
@det: Guter Beitrag - den sollte man mal ins Wiki übernehmen.
@dan1180:
Nochmal zu dem ersten Punkt: Wenn man selbst kein Verständnis von der Sache hat, sollte man sich nicht auf un-autorisierte Änderungen des Programmcodes einlassen, die von Autoren stammen, die ebenfalls nach eigenem Bekunden nicht programmieren können.
Nochmal zum zweiten Punkt: Mitnichten sehe ich darin einen "Angriff auf OWX", sondern ich habe ganz sachlich geschrieben, dass die Verzögerungen in diesem Falle nicht von OWX stammen können.
Allerdings sehe ich auch keinerlei Veranlassung, mich mit den Problemen von Leuten zu befassen, die Posts von mir als "kindisch" bezeichnen. Der einzige Rat, den ich gebe: Ein anständiges Interface mit Busmaster kaufen. Kostet um die 20 Euro und ist innerhalb von wenigen Tagen geliefert.
pah
@pah
ZitatAllerdings sehe ich auch keinerlei Veranlassung, mich mit den Problemen von Leuten zu befassen, die Posts von mir als "kindisch" bezeichnen.
Nichts für ungut. Ich habe nicht deinen Post als kindisch bezeichnet sondern EUREN Streit über die Definition eines Fehlers/Problems/Veraltetseins/Wieauchimmer eines Moduls. Es finden sich mehr als 10 Beiträge, die weder etwas mit der Analyse, noch mit der Lösung meines Problems (und ich dachte dazu sei ein Forum da) zu tun haben.Erwachsen finde ich das nicht. Übrigens auch nicht jetzt beleidigt zu sein nachdem ich dich in keiner Weise angegriffen habe. Wenn du nicht zur Lösung beitragen möchtest oder meine Meinung zu eurem Disput nicht akzeptierst dann schreib einfach nichts mehr zu diesem Beitrag aber fang jetzt nicht mit mir eine ähnliche Diskussion an wie mit Joachim. Dazu habe ich weder Zeit noch Lust und für mich ist das Thema somit auch erledigt.
@det
Vielen Dank. Ich habe den Artikel durchgearbeitet. Neue Hardware scheint ja, wenn wie bei mir nur FHEM darauf läuft, nicht notwendig zu sein. Die Abfragen meiner Sensoren habe ich alle auf event-on-change-reading gestellt. Was ich nicht ganz verstehe ist das Verhindern von Logs. Geht es darum die Logs aus dem fhem.log raus zu lassen oder bei einem selbsterstellten Log einzelne Events raus zu lassen?
Mittels apptime wurde seiner Zeit ermittelt, dass OWTHERM teilweise länger als 11 Sek. FHEM blockiert, was mich zu diesem Beitrag geführt hat. Das Modul 99_perfmon.pm habe ich nun installiert. Lass das jetzt mal ne Weile rennen und meld mich, wenn ich was zum angucken hab.
Zitat von: dan1180 am 27 April 2014, 11:10:13
Was ich nicht ganz verstehe ist das Verhindern von Logs. Geht es darum die Logs aus dem fhem.log raus zu lassen oder bei einem selbsterstellten Log einzelne Events raus zu lassen?
Es geht grundsätzlich darum, z.B. in den individuellen Filelogs Deiner Geräte nur das zu loggen, was Du wirklich brauchst. Jedes unnütze Event verbraucht Resourcen. Mach mal den Event Monitor an und schau was da alles kommt. Eliminiere alles, was Du da siehst und nicht zu irgendeiner Schalt/Anzeige oder sonst was Aufgabe benötigst.
Besonders eifrig sind da die Homematic Stellantriebe, als Beispiel mal einer aus einem der Gästezimmer:
define CUL_HM_HM_CC_RT_DN_24897F CUL_HM 24897F
attr CUL_HM_HM_CC_RT_DN_24897F IODev HMLAN1
attr CUL_HM_HM_CC_RT_DN_24897F actCycle 000:10
attr CUL_HM_HM_CC_RT_DN_24897F actStatus alive
attr CUL_HM_HM_CC_RT_DN_24897F autoReadReg 4_reqStatus
attr CUL_HM_HM_CC_RT_DN_24897F do_not_notify 1
attr CUL_HM_HM_CC_RT_DN_24897F expert 2_full
attr CUL_HM_HM_CC_RT_DN_24897F firmware 1.1
attr CUL_HM_HM_CC_RT_DN_24897F model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F peerIDs
attr CUL_HM_HM_CC_RT_DN_24897F room Unsorted
attr CUL_HM_HM_CC_RT_DN_24897F serialNr KEQ0959714
attr CUL_HM_HM_CC_RT_DN_24897F subType thermostat
attr CUL_HM_HM_CC_RT_DN_24897F webCmd getConfig:clear msgEvents:burstXmit
define CUL_HM_HM_CC_RT_DN_24897F_Weather CUL_HM 24897F01
attr CUL_HM_HM_CC_RT_DN_24897F_Weather do_not_notify 1
attr CUL_HM_HM_CC_RT_DN_24897F_Weather model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F_Weather peerIDs 00000000,
define CUL_HM_HM_CC_RT_DN_24897F_Climate CUL_HM 24897F02
attr CUL_HM_HM_CC_RT_DN_24897F_Climate do_not_notify 1
attr CUL_HM_HM_CC_RT_DN_24897F_Climate model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F_Climate peerIDs 00000000,
define CUL_HM_HM_CC_RT_DN_24897F_WindowRec CUL_HM 24897F03
attr CUL_HM_HM_CC_RT_DN_24897F_WindowRec do_not_notify 1
attr CUL_HM_HM_CC_RT_DN_24897F_WindowRec model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F_WindowRec peerIDs 00000000,
attr CUL_HM_HM_CC_RT_DN_24897F_WindowRec stateFormat last:trigLast
define CUL_HM_HM_CC_RT_DN_24897F_Clima CUL_HM 24897F04
attr CUL_HM_HM_CC_RT_DN_24897F_Clima alias hz_RON
attr CUL_HM_HM_CC_RT_DN_24897F_Clima event-on-change-reading state
attr CUL_HM_HM_CC_RT_DN_24897F_Clima group Raumheizung
attr CUL_HM_HM_CC_RT_DN_24897F_Clima model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F_Clima peerIDs 00000000,
attr CUL_HM_HM_CC_RT_DN_24897F_Clima room Residents
attr CUL_HM_HM_CC_RT_DN_24897F_Clima stateFormat measured-temp °C | Ventil: ValvePosition |
define CUL_HM_HM_CC_RT_DN_24897F_ClimaTeam CUL_HM 24897F05
attr CUL_HM_HM_CC_RT_DN_24897F_ClimaTeam do_not_notify 1
attr CUL_HM_HM_CC_RT_DN_24897F_ClimaTeam model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F_ClimaTeam peerIDs 00000000,
define CUL_HM_HM_CC_RT_DN_24897F_remote CUL_HM 24897F06
attr CUL_HM_HM_CC_RT_DN_24897F_remote do_not_notify 1
attr CUL_HM_HM_CC_RT_DN_24897F_remote model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_24897F_remote peerIDs 00000000,Da habe ich 6 (für meinen Fall) unnütze Events mit do not notify 1 verhindert. Das spart bei der Menge der eingesetzten Stellantriebe im FHEM echt viel Resourcen.
Moin pah,
ZitatNochmal zu dem ersten Punkt: Wenn man selbst kein Verständnis von der Sache hat, sollte man sich nicht auf un-autorisierte Änderungen des Programmcodes einlassen, die von Autoren stammen, die ebenfalls nach eigenem Bekunden nicht programmieren können.
Der Haken an der Sache ist, dass der Eigenbau danach erkannt wurde, und funktioniert hat. natürlich mit den Latenzen, die dem Eigenbau geschuldet sind.
Und zum finden von Problemen muss man nicht unbedingt programmieren können, logischer Menschenverstand und analytisches Denken reicht dafür oftmals aus.
Ich versuche wenigstens zu helfen, und behaupte nicht nur es geht, ohne Beweise zu liefern.
@ dan1180,
an Deiner Stelle würde ich mal meinen Lösungsweg
ZitatVariante 3, das FHEM mit 1-Wire als seperaten Prozess entweder auf der selben Hardware, oder einer abgesetzten Hardware laufen lassen, mittels FHEM2FHEM und cloneDevice die Sensoren auf das Hauptsystem clonen.
ausprobieren, das geht auch auf der gleichen Hardware, indem man die beiden FHEM Prozesse separat laufen lässt.
Einfach den fhem Ordner, den Du unter /opt findest, mit neuem Namen kopieren (z.B. fhem2), an die Berechtigungen denken, fhem.cfg anpassen (telnetport und Weboberflächenport ändern), HM-Einträge und sonstige Sachen, die mit OWX nichts zu tun haben, entfernen.
das 2. FHEM auf der Komandozeile im Verzeichnis /opt/fhem2 mit
perl fhem.pl fhem.cfgstarten.
Auf dem originalen fhem natürlich vorhel alles, was mit OWX zu tun hat entfernen, danach FHEM2FHEM und cloneDummy installieren, FHEM neu starten.
Dann mit apptime und Perfmon nachsehen wie die Latenzen sind.
Mich störte es allerding nicht, dass Du das Verhalten von mir und pah als kindisch bezeichnet hast, aber es hat Spass gemacht.
Gruß Joachim
Dann werd ich mir die Events nochmal genauer anschauen. Der PerformanceMonitor gab in den ersten 5 Minuten schon mehrere freezes >105 Sekunden aus! (Log im Anhang)
Außerdem noch die aktuelle Ausgabe von apptime:
name function max count total average maxDly
tmr-OWTHERM_GetValues HASH(0x1beb9e0) 7167 1 7167 7167.00 4 HASH(0x1beb9e0)
tmr-OWTHERM_GetValues HASH(0x1b6fa48) 7156 1 7156 7156.00 3 HASH(0x1b6fa48)
tmr-OWTHERM_GetValues HASH(0x1bec270) 7148 1 7148 7148.00 4 HASH(0x1bec270)
tmr-OWTHERM_GetValues HASH(0x1beb170) 7144 1 7144 7144.00 4 HASH(0x1beb170)
tmr-OWTHERM_GetValues HASH(0x1bb38b0) 7139 1 7139 7139.00 4 HASH(0x1bb38b0)
tmr-OWTHERM_GetValues HASH(0x1beb5a8) 7121 1 7121 7121.00 5 HASH(0x1beb5a8)
tmr-OWTHERM_GetValues HASH(0x1bec6a8) 7121 1 7121 7121.00 5 HASH(0x1bec6a8)
tmr-OWTHERM_GetValues HASH(0x1bebe18) 7117 1 7117 7117.00 5 HASH(0x1bebe18)
tmr-OWTHERM_GetValues HASH(0x1be8e48) 7114 1 7114 7114.00 4 HASH(0x1be8e48)
FHEMWEB:192.168.2.103:49980 FW_Read 2304 6 2356 392.67 0 HASH(0x1ee8800)
HMLAN1 HMLAN_Read 185 13 585 45.00 0 HASH(0x1614e40)
HMLAN1 HMLAN_Ready 88 46 109 2.37 0 HASH(0x1614e40)
tmr-OWX_Kick HASH(0x1597230) 38 1 38 38.00 4 HASH(0x1597230)
tmr-FW_closeOldClients 20 3 24 8.00 4279
eventTypes eventTypes_Notify 11 16 112 7.00 0 HASH(0x1592750); HASH(0x1b56640)
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 8 5 24 4.80 7162 keepAlive:HMLAN1
SSP_LOG FileLog_Log 7 16 38 2.38 0 HASH(0x1becae0); HASH(0x1c93d80)
FHEMWEB:192.168.2.103:49981 FW_Read 6 4 21 5.25 0 HASH(0x1d17698)
FHEMWEB:192.168.2.103:49982 FW_Read 6 2 11 5.50 0 HASH(0x1f262a8)
FHEMWEB:192.168.2.103:49983 FW_Read 6 2 12 6.00 0 HASH(0x1f07ed8)
HMLAN1 HMLAN_Notify 6 16 6 0.38 0 HASH(0x1614e40); HASH(0x1614e40)
Das ist doch nicht normal...Muss wohl jetzt auf das aktive Interface mit Spannungsversorgung warten. Ansonsten macht wohl alle weitere Analyse keinen Sinn :(
Sollte noch jemand einen Tipp haben, gerne her damit. Ansonsten wür ich mich melden, wenn ich das neue Teil angeschlossen habe.
@Joachim
Werd die Variante mal, solange ich auf meinen BUS warte, testen. Du hast ziemlich am Anfang mal geschrieben, dass unter Umständen trotzdem ein Fehler auftreten kann. Ich hab etwas Angst, dass ich mich dann auf FHEM verlasse, weil es ein paar Tage lang fuunktioniert, und dann verlassen werde... :-\
Zitat von: Prof. Dr. Peter Henning am 26 April 2014, 09:56:35
@det: Den hier meinst Du ? http://www.legacy.com/obituaries/pressconnects/obituary.aspx?pid=169499088 (http://www.legacy.com/obituaries/pressconnects/obituary.aspx?pid=169499088)
LG
pah
@ pah,
Diesen Bosnick kannte ich noch nicht, allerdings wenn ich das English richtig verstanden habe war er nicht halb so sarkastisch wie pah, det. und weitere hier im Forum. Seit Harald Schmidt nicht mehr gen Mitternacht über andere Leute herzieht, ist das Forum hier dafür ein sehr vergnüglicher Ersatz - Technik mit viel Unterhaltungswert.
@ dan1180,
ZitatDu hast ziemlich am Anfang mal geschrieben, dass unter Umständen trotzdem ein Fehler auftreten kann
Das ist richtig allerdings hatte ich nie gesucht, wo der Fehler herkam, da mit der FHEM2FHEM Variante mein HM un MAX zufriedenstellen lief, und es für mich keinen Grund gab, hier weiter zu suchen. Im Anhang mal Apptime von einem Testsystem, das mittel FHEM2FHEM an das "OWX" System angebunden ist.
Gruß Joachim
PS:Wie man in Deinem angehängten Log hervorragend sieht, ist es OXW, dass Dein System die 105 Sekunden anhält.
habe da jetzt keine Lust zu suchen, warum. Nicht dass ich wieder einen Designfehler finde, und pah damit angreife.
OK. Also vernachlässigbar. Ich versuchs einfach mal. Falls du doch Lust bekommst und nach der Ursache suchst kannst du es ja z.B, D-Fehler nennen. Mur ist es nämlich, wie schon geschrieben, sch...egal wie das Problem heißt. Ich bin aber brennend an einer Lösung interessiert.
Danke mal wieder!
Moin dan1180,
viel Glück, wenn es Probleme beim Installieren gibt, bescheid sagen.
Dass es Dir als Endanwender sch...egal ist, wie das ganze genannt wird, ist mir volkommen klar und verständlich.
Wenn man dann tiefer in die Analyse der Programmierung einsteigt, dann ändert sich das.
Denn dann muß man da durchaus trennen, welcher Art das Problem ist, um dem Programmierer nicht unrecht zu tun.
Gruß Joachim
PS.: Ich habe das "böse Wort" weggelassen.
@det.:Auch das lustige Programmzeilenraten hier ist eigentlich ganz interessant. Nach dem Inifinite-Monkey-Theorem wird das zu einer stark verbesserten Ausgabe von FHEM im Allgemeinen und OWX im speziellen führen. Bin gespannt.
pah
Mensch pah,
Du entwickelst Dich immer mehr zum Foren-Troll.
ZitatAls Troll bezeichnet man im Netzjargon eine Person, welche die Kommunikation im Internet fortwährend und auf destruktive Weise dadurch behindert, dass sie Beiträge verfasst, die sich auf die Provokation anderer Gesprächsteilnehmer beschränken und keinen sachbezogenen und konstruktiven Beitrag zur Diskussion darstellen. In darauf bezogenen Bildern wird oft auf den aus der Mythologie bekannten Troll verwiesen. Ein gelegentlich gebrauchtes Synonym ist Twit (engl: Dummkopf).
Quelle:
http://de.wikipedia.org/wiki/Troll_%28Netzkultur%29
hast Du das wirklich nötig?
Gruß Joachim
Hallo Joachim,
FHEM ist kopiert, fhem.cfg editiert und auch der Start der zweiten Instanz scheint funktioniert zu haben (kein Meckern beim Startbefehl). Nun jedoch folgenden Probleme:
1. Muss ich nach dem "define ... FHEM2FEHM..." irgendwelche Attribute setzen?
2. Startet die 2. Instanz von FHEM auch immer automatisch bei einem Reboot des RasPi?
3. Kannst du mir bitte den clonedummy erklären? Was muss ich da machen? Finde zwar dummy in der Commandref aber keine Erklärung für den clone...
Danke!
Moin dan1180,
Als erstes ausprobieren, ob Du auf Deine neue FHEM Instanz über einen Browser heraufkommst, also:
localhost:8073/fhem
localhost ist glaube ich klar, und die 8073 mit dem Port ersetzen, den Du in der fhem.cfg angegeben hast, nicht 8083, 8084 oder 8085, die sind ja schon von Deinem Hauptfhem belegt.
Zitat1. Muss ich nach dem "define ... FHEM2FEHM..." irgendwelche Attribute setzen?
z.B.:
define meinOWX FHEM2FHEM localhost:7072 LOG:.*
naürlich auf Deinem HauptFHEM, wobei auch hier der Port anzupassen ist, und natürlich nicht mit dem telnetport Deines Hauptfhems übereinstimmen sollte. Also wie oben schon beschrieben den telnetport Deines OWXFHEMs in der cfg ändern, und diese Änderung dann im def eintragen.
Zitat2. Startet die 2. Instanz von FHEM auch immer automatisch bei einem Reboot des RasPi?
Nein, das war jetzt nur ein direkter Start von FHEM, wenn das nachher automatisch gehen soll, dann muß in init.d noch etwas angepasst werden.
Zitat3. Kannst du mir bitte den clonedummy erklären? Was muss ich da machen? Finde zwar dummy in der Commandref aber keine Erklärung für den clone...
Musst Du noch üben, mit dem Suchen.
Zitat
cloneDummy
Definiert einen Clon eines Devices oder von FHEM2FHEM im Logmodus uebergebenen Devices und uebernimmt dessen Readings. Sinnvoll um entfernte FHEM-Installationen lesend einzubinden, zum Testen oder Programmieren.
Define
define <name> cloneDummy <Quelldevice> [reading]
Aktiviert den cloneDummy, der dann an das Device <Quelldevice> gebunden ist. Mit dem optionalen Parameter reading wird bestimmt, welches reading im STATE angezeigt wird, stateFormat ist auch weiterhin möglich.
Beispiel: Der cloneDummy wird lesend an den Sensor OWX_26_09FF26010000 gebunden und zeigt im State temperature an.
define Feuchte cloneDummy OWX_26_09FF26010000 temperature
Set
N/A
Get
N/A
Attributes
clonIgnore
Eine durch Kommata getrennte Liste der readings, die cloneDummy nicht in eigene readings umwandelt
readingFnAttributes
Wichtig: Es müssen unterschiedliche Namen für <name> und <Quelldevice> verwendet werden!
Gruß Joachim
Nabend...
ZitatAls erstes ausprobieren, ob Du auf Deine neue FHEM Instanz über einen Browser heraufkommst
Ja ich komm drauf und es scheint soweit auch alles zu passen (1 Instanz HM, 1 Instanz OWX). Ich habe alle Ports umbenannt und keinen doppelt.
Zitatdefine meinOWX FHEM2FHEM localhost:7072 LOG:.*
Habe ich entsprechend gemacht und hat funktioniert.
ZitatNein, das war jetzt nur ein direkter Start von FHEM, wenn das nachher automatisch gehen soll, dann muß in init.d noch etwas angepasst werden.
Ist das die selbe Anpassung, die auch schon in der Installationsanleitung für FHEM steht (fischer-net.de)?
ZitatMusst Du noch üben, mit dem Suchen.
Ich find in der Commandref wirklich nur den dummy, nicht aber den cloneDummy. Nichts desto trotz habe ich folgendes gemacht:
define C_AUT_ND cloneDummy AUT_ND temperatureLeider werden bisher noch keine Werte übertragen. Fehlt beim cloneDummy noch eine Pfadangabe auf das andere FHEM?
Das Listing meines Dummys:
Internals:
DEF AUT_ND temperature
NAME C_AUT_ND
NOTIFYDEV AUT_ND
NOTIFYSTATE temperature
NR 179
NTFY_ORDER 50-C_AUT_ND
STATE 0.0°C
TYPE cloneDummy
Readings:
2014-04-27 15:39:41 state defined
Attributes:
room Heizung
stateFormat {sprintf("%.1f",ReadingsVal("C_AUT_ND","temperature",0))."°C"}
Edit nach 2 Minuten:
Hab cloneDummy gefunden. Muss zugeben, dass ich, nachdem ich alphabetisch an "C" vorbei war, nicht mehr weiter gesucht habe :-/
@dan1180,
das wird ja ein abenteuerliches Konstrukt - mal einen Gedanken an einen 2ten RPI oder was schnelleres verschwendet - ist zum Testen auf jeden Fall die sicherere, einfachere und stabilere Alternative. Natürlich nur, wenn das produktive FHEM schon wirklich zu etwas Nützlichem im Einsatz ist, sonst ist es sicher egal.
Moin dan1180,
mal zum abschreiben (aber natürlich an Deine Gegebenheiten anpassen) einen Auszug aus meinem Hauptfhem:
define FB7390 FHEM2FHEM 172.16.19.10:7072 LOG:.*
attr FB7390 room OWX
define clone_TS_Bad cloneDummy TS_Bad Temperatur
attr clone_TS_Bad cloneIgnore T,temperature
attr clone_TS_Bad room test
attr clone_TS_Bad stateFormat _state
define clone_TS_Bue cloneDummy TS_Bue
attr clone_TS_Bue room test
attr clone_TS_Bue stateFormat {sprintf("%.1f",ReadingsVal("clone_TS_Bue","Temperatur",0))." °C"}Zwei verschidene Varianten, die bei mir laufen, allerdings habe ich auf meinem "OXFHEM" ein userReading, dass T und temperature auf Temperatur unsetzt.
Zum Testen mal den Eventmonitor anwerfen, da sollten die entsprechenden Readings ankommen.
2014-04-27 16:14:57.514 OWTHERM TS_Gefrierschrank Temperatur: -22.3
@ det.
Zitatdas wird ja ein abenteuerliches Konstrukt
nicht wirklich, es macht fast das gleiche, wie OWX_ASYNCRON, nur in einer seperaten Instanz, in der OWX FHEM beliebig bremsen kann, und hat den Vorteil, dass keine 2. Hardware gebraucht wird.
Gruß Joachim
Also bei mir sieht das so aus:
define F2F FHEM2FHEM 192.168.2.150:8093 LOG:.*
attr F2F room Controller
define C_AUT_ND cloneDummy AUT_ND temperature
attr C_AUT_ND fp_Heizung 90,855,0
attr C_AUT_ND room Heizung
attr C_AUT_ND stateFormat {sprintf("%.1f",ReadingsVal("C_AUT_ND","temperature",0))."°C"}
Ich seh da nicht wirklich einen Unterschied zu deiner Ausführung. Naja, außer, dass es bei dir funktioniert...
@det
Abenteuerlich weshalb? Also bisher find ichs noch reht übersichtlich. Einen zweiten RasPi möchte ich für die Haussteuerung nicht. Ein schnellerer Verwandter schwebt mir auch im Kopf rum aber frühestens wenn ich das alles im Griff habe. Im Moment stecke ich noch ziemlich in den Kinderschuhen (auch wenn ich meine HM Fußbodenheizungsregelung glaub ganz gut im Griff habe) weshalb ich ohne viel Angst noch ein bisschen testen kann ;-)
Was sagt der Event monitor?
Im Event Monitor kein Wort von meinem cloneDummy oder FHEM2FHEM.
Im Log finde ich folgendes, was sich regelmäßig wiederholt:
2014.04.27 16:29:41.651 5: HMLAN_Parse: HMLAN1 R:E262403 stat:0000 t:03DDE721 d:FF r:FFB0 m:AC 8470 262403 000000 00D92D
2014.04.27 16:29:41.653 5: HMLAN1 dispatch A0CAC847026240300000000D92D::-80:HMLAN1
2014.04.27 16:29:41.665 5: Triggering WTS_WZ_Weather (3 changes)
2014.04.27 16:29:41.666 5: Notify loop for WTS_WZ_Weather temperature: 21.7
2014.04.27 16:29:41.682 4: eventTypes: CUL_HM WTS_WZ_Weather temperature: 21.7 -> temperature: .*
2014.04.27 16:29:41.684 4: eventTypes: CUL_HM WTS_WZ_Weather humidity: 45 -> humidity: .*
2014.04.27 16:29:41.685 4: eventTypes: CUL_HM WTS_WZ_Weather T: 21.7 H: 45 -> T: .* H: .*
2014.04.27 16:29:41.686 4: eventTypes: CUL_HM WTS_WZ_Weather state: T: 21.7 H: 45 -> state: T: .* H: .*
2014.04.27 16:29:44.015 4: Connection closed for FHEMWEB:192.168.2.103:51631
2014.04.27 16:29:44.025 4: HTTP FHEMWEB:192.168.2.103:51633 GET /fhem?detail=C_AUT_ND
2014.04.27 16:29:44.337 4: /fhem?detail=C_AUT_ND / RL:2238 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.04.27 16:29:44.369 4: HTTP FHEMWEB:192.168.2.103:51633 GET /fhem/pgm2/style.css
2014.04.27 16:29:44.378 4: HTTP FHEMWEB:192.168.2.103:51630 GET /fhem/pgm2/fhemweb.js
2014.04.27 16:29:44.384 4: Connection accepted from FHEMWEB:192.168.2.103:51634
2014.04.27 16:29:44.387 4: HTTP FHEMWEB:192.168.2.103:51632 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.04.27 16:29:44.393 4: HTTP FHEMWEB:192.168.2.103:51629 GET /fhem/pgm2/svg.js
2014.04.27 16:29:44.401 4: HTTP FHEMWEB:192.168.2.103:51634 GET /fhem/pgm2/fhemweb_multiple.js
2014.04.27 16:29:44.407 4: HTTP FHEMWEB:192.168.2.103:51630 GET /fhem/pgm2/fhemweb_slider.js
2014.04.27 16:29:44.413 4: HTTP FHEMWEB:192.168.2.103:51632 GET /fhem/pgm2/fhemweb_svg.js
2014.04.27 16:29:44.420 4: HTTP FHEMWEB:192.168.2.103:51633 GET /fhem/pgm2/fhemweb_noArg.js
2014.04.27 16:29:44.427 4: HTTP FHEMWEB:192.168.2.103:51634 GET /fhem/pgm2/fhemweb_time.js
2014.04.27 16:29:44.433 4: HTTP FHEMWEB:192.168.2.103:51630 GET /fhem/pgm2/dashboard_style.css
2014.04.27 16:29:44.438 4: HTTP FHEMWEB:192.168.2.103:51632 GET /fhem/icons/favicon
2014.04.27 16:29:44.445 4: HTTP FHEMWEB:192.168.2.103:51629 GET /fhem/pgm2/fhemweb_textField.js
2014.04.27 16:29:44.501 4: HTTP FHEMWEB:192.168.2.103:51633 GET /fhem/images/default/icoEverything.png
2014.04.27 16:29:44.509 4: HTTP FHEMWEB:192.168.2.103:51634 GET /fhem/images/default/fhemicon.png
2014.04.27 16:29:44.515 4: HTTP FHEMWEB:192.168.2.103:51629 GET /fhem?cmd={AttrVal(%22C_AUT_ND%22,%22room%22,%22%22)}&XHR=1
2014.04.27 16:29:44.518 5: Cmd: >{AttrVal("C_AUT_ND","room","")}<
2014.04.27 16:29:44.544 4: /fhem?cmd={AttrVal(%22C_AUT_ND%22,%22room%22,%22%22)}&XHR=1 / RL:28 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2014.04.27 16:29:44.640 4: HTTP FHEMWEB:192.168.2.103:51633 GET /fhem?XHR=1&inform=type=status;filter=C_AUT_ND×tamp=1398608984132
2014.04.27 16:30:04.022 5: HMLAN_Send: HMLAN1 I:K
2014.04.27 16:30:04.033 5: HMLAN/RAW: /HHM-LAN-IF,03C1,KEQ1023876,257722,DD0111,03DE3EE6,0004
2014.04.27 16:30:04.036 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ1023876 d:257722 O:DD0111 t:03DE3EE6 IDcnt:0004
2014.04.27 16:30:16.056 4: HTTP FHEMWEB:192.168.2.103:51629 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2014-04.log
FHEM2FHEM sagt connected und Fehlermeldungen bekomm ich auch nicht.
Edit: Hatte die Verbindung via WEB Port gemacht. Hab jetzt auf den Telnet Port umdefiniert. Macht das einen Unterschied? Ergebnis ist bisher das Selbe (connected aber kein Wert)
Kontrollier mal die IP's.
192.168.2.103
oder
192.168.2.150 ?
Beide FHEM Installationen laufen duch auf dem gleichen Rechner?
Gruß Joachim
Die 150 passt und wie du unten siehst hab ich die auch definiert. Ich komm auch über den WEB Port mit der 150 auf beide Installationen. Warum im Log die 103 auftaucht ist mir ein Rätsel. Unter 103 ist die das Notebook im Netzwerk mit dem ich FHEM im Browser aufruf und mit dem ich mittels Remote Desktop auf mienem RasPi arbeite.
Läuft OWX auf Deinen OWX-System?
Mal bitte von beiden Systemen einen Auszug aus dem Eventmonitor, an besten, wenn Werte von OWX geliefert werden.
Gruß Joachim
OK, ich hab wohl selbst herausgefunden woran es hakt 8) (iiich habe Feuer gemacht!!!)
Spaß bei Seite. Es scheint so als würde fhem, wenn die Sensoren auf event-on-change-reading stehen zum einen keine Events ausgeben (Event-Liste war nach 15 Minuten noch leer), zum anderen keine Readings schreiben oder weiter geben. Seit ich ein paar Sensoren auf Interval gestellt habe werden Events geschrieben und TATAAA...mein Haupt FHEM holt sich die Werte.
Ein paar kleine Fragen hätt ich noch:
- Wird mein Haupt fhem immer getriggert wenn fhem_owx ein Event schreibt?
- Kann man theoretisch beliebig viele FHEMs miteinander betreiben oder ist das auf zwei begrenzt?
- Muss ich meine Logs, die ich für Plots im Hauptsystem verwenden will auch in diesem schreiben oder kann ich mir die Werte holen?
Ich werde jetzt mal all meine Sensoren umstellen. Hätte zwar gerne nur Werte geschrieben wenn sie sich ändern aber man kann halt nicht alles haben. Meld mich sobald ich mein System auf Vordermann hab und mal ein paar Stunden Logfile lesen konnte.
Joachim, vielen Dank! Ist zwar nicht die Lösung des Problems aber wohl ein geschickter Weg drum herum.
Schön, dass es jetzt geht,
mich würde dann auch mal von Deinem Hauptfhem Apptime interessieen.
ZitatEs scheint so als würde fhem, wenn die Sensoren auf event-on-change-reading stehen zum einen keine Events ausgeben (Event-Liste war nach 15 Minuten noch leer),
Bei event-on-change-reading kommen nur dann readings, wenn sich etwas ändert, möchtest Du öfter Werte bekommen, dann brauchst Du zusätzlich event-min-interval, z.B. so:
define TS_Bad OWTHERM DS18B20 2118BA030000 300
attr TS_Bad IODev LinkUSBi
attr TS_Bad event-min-interval Temperatur:600
attr TS_Bad event-on-change-reading Temperatur
attr TS_Bad model DS1822
attr TS_Bad room Bad
attr TS_Bad stateFormat {( int (ReadingsVal("TS_Bad","temperature",0) * 10 + 0.5 ) / 10)." °C"}
attr TS_Bad tempHigh 25
attr TS_Bad tempLow 0
attr TS_Bad tempOffset 0.0
attr TS_Bad userReadings Temperatur {(ReadingsVal("TS_Bad","Temperatur",0) eq "0") ? ( int (ReadingsVal("TS_Bad","temperature",0) * 10 + 0.5 ) / 10):( int (((ReadingsVal("TS_Bad","temperature",0) + ReadingsVal("TS_Bad","Temperatur",0)) / 2 ) * 10 + 0.5 ) / 10)}
Zu Deinen Fragen:
1. Ja, immer wenn ein Event in Deinem FHEMOWX kommt, sollte dieser über FHEM2FHEM auf Deinem Hauptsystem ankommen.
2. Theoretisch sind unbegrenzt viele FHEM nebeneinander möglich,ab wann das unkonfortalel läuft hängt von der Rechenleistung ab.
3. Bleibt Dir überlassen, besser ist aber, wenn die Logs auf dem Hauptfhem geschrieben werden. Da es sonst Probleme mit dem Zusammenspiel von SVG und FileLog geben kann.
Du musst jetzt noch daran denken, dafür zu sorgen, dass Dein FHEMOWX automatisch mit gestartet wird, dafür muss das init-Script angepasst werden. Da ich das auch nachlesen muß, kannst Du das auch selbst.
Gruß Jaochim
name function max count total average maxDly
F2F FHEM2FHEM_Read 405 2 801 400.50 0 HASH(0x19425b8)
C_FBH_RL cloneDummy_Notify 36 1 36 36.00 0 HASH(0x1936590); HASH(0xfa5c88)
C_WHK_RL cloneDummy_Notify 31 3 80 26.67 0 HASH(0x18fe650); HASH(0x190d370)
C_WHK_VL cloneDummy_Notify 31 3 84 28.00 0 HASH(0x18fefc8); HASH(0x1830e68)
C_FBH_VL cloneDummy_Notify 30 3 81 27.00 0 HASH(0x18feb30); HASH(0x1b71368)
C_OBK_RL cloneDummy_Notify 29 3 83 27.67 0 HASH(0x17bf0c8); HASH(0x1b1aca0)
C_SSP_UU cloneDummy_Notify 28 3 78 26.00 0 HASH(0x1830898); HASH(0x1c63460)
eventTypes eventTypes_Notify 11 32 100 3.12 0 HASH(0x12a9cc0); HASH(0x1936590)
FHEMWEB:192.168.2.103:53376 FW_Read 9 2 13 6.50 0 HASH(0x1c5a240)
FHEMWEB:192.168.2.103:53363 FW_Read 8 2 14 7.00 0 HASH(0x128cd38)
FHEMWEB:192.168.2.103:53366 FW_Read 8 3 12 4.00 0 HASH(0x1b6e198)
WEB FW_Read 8 1 8 8.00 0 HASH(0x1b046e8)
FHEMWEB:192.168.2.103:53362 FW_Read 7 3 17 5.67 0 HASH(0x1912138)
FHEMWEB:192.168.2.103:53365 FW_Read 7 2 13 6.50 0 HASH(0x1b035b8)
SSP_LOG FileLog_Log 5 32 62 1.94 0 HASH(0x1648b30); HASH(0x18feb30)
HMSA4.1_LOG FileLog_Log 4 32 24 0.75 0 HASH(0x190b8b0); HASH(0x1b75458)
HMSA4.2_LOG FileLog_Log 4 32 13 0.41 0 HASH(0x12a9a80); HASH(0x18fefc8)
WTR_LOG FileLog_Log 4 32 22 0.69 0 HASH(0x128d1d0); HASH(0x1b1f5e8)
Logfile FileLog_Log 3 32 7 0.22 0 HASH(0x1c5c630); HASH(0x17bf0c8)
HMLAN1 HMLAN_Notify 2 32 5 0.16 0 HASH(0x1c45b88); HASH(0xfa5c88)
WEB FW_Notify 2 32 2 0.06 0 HASH(0x1b046e8); HASH(0x1c5bdd8)
Bitteschön!
Das heißt wenn ich nur geänderte Werte will muss ich event-on-change-reading und event-min-interval kombinieren? Mich hat halt verwundert, dass (nur mit event-on-change-reading) sich zwar die Temperaturen geändert haben aber kein Event ausgegeben wurde.
Das mit dem Autostart bekomm ich sicher hin. Vielen Dank auf jeden Fall! Ich werd dann nochmal reporten wenn ich alles mal ne Weile laufen hatte.
Na, das sieht doch gut aus.
hier der Auszug aus der comandref:
event-on-change-reading
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings". Wenn gesetzt, erzeugen nur Veränderungen der gelisteten "readings" ein Ereignis. Wenn die aktualiserten Werte der gelisteten "readings" identisch sind, wird kein Ereignis generiert.
Die unterschiedlichen Bedeutungen von event-on-update-reading und event-on-change-reading sind folgende:
Wenn beide Attribute nicht gesetzt sind erzeugt jede Aktualisierung eines jeden "readings" eines Gerätes ein Ereignis.
Wenn eines der Attribute gesetzt ist, erzeugen nur Updates oder änderungen von "readings" die nicht in einem der Attribute gesetzt sind ein Ereignis.
Wenn ein "reading" in event-on-update-reading aufgeführt ist, erzeugt eine Aktualisierung ein Ereignis unabhängig ob das "reading" auch in event-on-change-reading aufgelistet ist.
event-min-interval
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings:minInterval" Paare. readings kann ein regexp sein. Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind.
von daher sollte ein geänderter Wert auf jeden fall einen Event auslösen, even-min-intervall setzt nur eine Mindestzeit, nach der auf jeden Fall geloggt wird.
Wenn Du mich auf dem laufenden hältst, wäre das super, damit ich auch dem nächsten die Lösung empfehlen kann, wenn es mal wieder ein Problem gibt. Eventuell wäre nocheinmal die veränderte Systemlast mit einem gegen zwei FHEM interessant.
Gruß Joachim
Hallo Joachim,
ich weiß selbst nicht warum aber manchmal steh ich wie der Ochse vorm Berg. Mein event-on-change-reading hat nicht funktioniert, weil ich dem Befehl kein reading gegeben habe das er ausgeben soll. In meiner fhem.cfg stand "attr XXX event-on-change-reading". Seit ich nun die Zeile mit "temperature" ergänzt habe funkntioniert alles bestens. Sorry, da hätt ich dir noch etwas Arbeit sparen können.
Den automatischen Start meiner zweiten FHEM Installation habe ich über die rc.local gelöst. Dort habe ich folgende Zeilen vor "exit (0)" geschrieben:
cd /opt/fhem_owx
sudo perl fhem.pl fhem.cfg
Selbstverständlich werde ich dich und alle Anderen, die es interessiert, auf dem Laufenden halten. Ich werde die Geschichte mal ein paar Stunden/Tage laufen lassen und ab und an ein apptime ausführen. Meine Erfahrungen schreib ich dann.
Vielen Dank und einen schönen Wochenanfang! ;)
So, nun nach ein paar Tagen meine ersten Erfahrungen. Es gab keinen einzigen Ausstieg meines HM-CC-VD Stellantrieb (den ich übrigens mittlerweile über PID20 mit einem TC-IT regeln kann 8) ).
Ein aktuelles "apptiem" (02.05.2014-16:04)
name function max count total average maxDly
HMLAN1 HMLAN_Read 100 24 834 34.75 0 HASH(0x10677a8)
F2F FHEM2FHEM_Read 71 5 269 53.80 0 HASH(0xf0ea30)
tmr-CUL_HM_respPendTout respPend:100001 61 2 121 60.50 4 respPend:100001
tmr-CUL_HM_valvePosUpdt valvePos:10000101 53 2 98 49.00 3 valvePos:10000101
tmr-PID20_Calc PID_HKS_BD 46 3 71 23.67 3 PID_HKS_BD
tmr-CUL_HM_valvePosTmr valveTmr:10000101 43 2 62 31.00 3 valveTmr:10000101
N_WTS_BD notify_Exec 39 2 77 38.50 0 HASH(0x107abc0); HASH(0x10bd4e8)
C_AUT_ND cloneDummy_Notify 28 1 28 28.00 0 HASH(0x10ca998); HASH(0x10be088)
C_SSP_OO cloneDummy_Notify 27 1 27 27.00 0 HASH(0x10dfc40); HASH(0x132f0f8)
C_FBH_RL cloneDummy_Notify 25 1 25 25.00 0 HASH(0x10ef490); HASH(0x10087e0)
C_KOL_RL cloneDummy_Notify 25 1 25 25.00 0 HASH(0x1075da8); HASH(0xf7fb60)
C_OBK_LT cloneDummy_Notify 25 1 25 25.00 0 HASH(0x132e178); HASH(0xf6c3f0)
PID_HKS_BD PID20_Set 23 2 42 21.00 0 HASH(0x10e62f8); PID_HKS_BD; desired; 21.5
tmr-FW_closeOldClients 19 3 25 8.33 8
tmr-CUL_HM_ActCheck ActionDetector 17 1 17 17.00 3 ActionDetector
eventTypes eventTypes_Notify 10 40 169 4.22 0 HASH(0xf28188); HASH(0x109de10)
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 10 7 49 7.00 3 keepAlive:HMLAN1
WEB FW_Read 9 13 59 4.54 0 HASH(0x10dd520)
PID_HKS_BD PID20_Notify 7 40 12 0.30 0 HASH(0x10e62f8); HASH(0x10bd4e8)
FHEMWEB:192.168.2.103:59230 FW_Read 6 6 31 5.17 0 HASH(0x10b9998)
FHEMWEB:192.168.2.103:59233 FW_Read 6 3 16 5.33 0 HASH(0x135de58)
Ich werde diesen BEitrag noch bis Sonntag für Fragen und Kommentare offen lassen und ihn dann mit einem abschließenden Bericht und einer Zusammenfassung als gelöst markieren und schließen. Danke an alle, vor allem an Joachim.
Moin dan1180,
das sieht doch genial aus. Schlechteste Verzögerung 100ms. Damit kann man herorragend leben.
Wie sieht es mit der Systemlast des pi aus, Vergleich 1x FHEM gegen 2x FHEM?
Ic glaube, ich kann diese Variante dann so bedenkenlos weiterenpfehlen.
Gruß Joachim
Hallo Joachim,
ja ich bin auch sehr zufrieden. Wie kann ich dir die Systemlast zeigen? Gibts da auch ne Art log?
Gruß Daniel
Neues apptime. Etwas schlechter aber ich denke immer noch gut oder?
name function max count total average maxDly
HMLAN1 HMLAN_Read 579 2665 96593 36.25 0 HASH(0x10677a8)
F2F FHEM2FHEM_Read 259 982 50500 51.43 0 HASH(0xf0ea30)
tmr-PID20_Calc PID_HKS_BD 175 356 6860 19.27 45 PID_HKS_BD
V_HKS_BD CUL_HM_Set 114 27 1230 45.56 0 HASH(0x10e5d28); V_HKS_BD; valvePos; 28
tmr-CUL_HM_procQs CUL_HM_procQs 110 1 110 110.00 3 CUL_HM_procQs
HMLAN1 HMLAN_Ready 95 3 264 88.00 0 HASH(0x10677a8)
tmr-CUL_HM_respPendTout respPend:100001 83 36 2315 64.31 5 respPend:100001
WTS_BD_Climate CUL_HM_Set 80 13 230 17.69 0 HASH(0x10bd4e8); WTS_BD_Climate; desired-temp; 20.0
tmr-CUL_HM_respPendTout respPend:254AEA 78 4 106 26.50 4 respPend:254AEA
tmr-CUL_HM_ActCheck ActionDetector 75 36 1042 28.94 4 ActionDetector
tmr-HMLAN_KeepAliveCheck keepAliveCk:HMLAN1 72 867 266 0.31 85 keepAliveCk:HMLAN1
N_WTS_BD notify_Exec 54 145 5278 36.40 0 HASH(0x107abc0); HASH(0x10bd4e8)
tmr-CUL_HM_valvePosUpdt valvePos:10000101 53 141 3777 26.79 5 valvePos:10000101
C_SSP_OO cloneDummy_Notify 47 71 2301 32.41 0 HASH(0x10dfc40); HASH(0x736088)
C_KOL_RL cloneDummy_Notify 44 158 4805 30.41 0 HASH(0x1075da8); HASH(0x12ceb90)
tmr-CUL_HM_valvePosTmr valveTmr:10000101 43 141 930 6.60 52 valveTmr:10000101
C_OBK_RL cloneDummy_Notify 40 34 1035 30.44 0 HASH(0xf016a0); HASH(0x13a5208)
C_OBK_VL cloneDummy_Notify 40 48 1661 34.60 0 HASH(0x12fc560); HASH(0x12f8390)
C_FBH_RL cloneDummy_Notify 38 29 800 27.59 0 HASH(0x10ef490); HASH(0x13a51f0)
PID_HKS_BD PID20_Set 38 175 2925 16.71 0 HASH(0x10e62f8); PID_HKS_BD; desired; 21.5
C_KOL_VL cloneDummy_Notify 36 70 1938 27.69 0 HASH(0xf27c58); HASH(0x1334c90)
Systemlast anzeigen, ohne FHEM zu bremsen:
http://rpi-experiences.blogspot.de/p/rpi-monitor.html
Apptime immer noch super.
Gruß Joachim
So, hab nun RPI Monitor laufen. Lass jetzt mal ne Weile aufzeichnen und poste dir dann das Ergebnis. Was möchtest du sehen? Grafik CPU Last? Brauchst du dann auch das Logfile um zu sehen ob ein peak mit fhem zu tun hat?
Danke nochmal, Dan
Hallo Joachim,
im Anhang der erste Graph des RPI Monitors. Kann es sein, dass durch die Aufzeichnung mein RPI spinnt? Ich hab teilweise wieder sehr lange Wartezeiten und heute Nacht um 4 ist mein ganzes System zusammengebrochen.
Mein schlechtestes apptime aus 15 Min. wiederholender Eingabe (Womit ich ganz zufrieden bin):
name function max count total average maxDly
FHEMWEB:192.168.2.103:49386 FW_Read 365 12 433 36.08 0 HASH(0x1c54410)
HMLAN1 HMLAN_Read 103 11 445 40.45 0 HASH(0x1388978)
F2F FHEM2FHEM_Read 79 5 312 62.40 0 HASH(0x1929268)
tmr-CUL_HM_respPendTout respPend:100001 58 1 58 58.00 2 respPend:100001
tmr-CUL_HM_valvePosUpdt valvePos:10000101 55 1 55 55.00 3 valvePos:10000101
tmr-PID20_Calc PID_HKS_BD 50 1 50 50.00 3 PID_HKS_BD
N_WTS_BD notify_Exec 34 1 34 34.00 0 HASH(0x1962cc8); HASH(0x1826978)
C_KOL_RL cloneDummy_Notify 33 1 33 33.00 0 HASH(0x1939a40); HASH(0x1c0a7b0)
C_KOL_VL cloneDummy_Notify 32 1 32 32.00 0 HASH(0x1939968); HASH(0x1c6d908)
C_SSP_MM cloneDummy_Notify 29 1 29 29.00 0 HASH(0x1938f70); HASH(0x1c473a0)
C_OBK_RL cloneDummy_Notify 27 1 27 27.00 0 HASH(0x193a130); HASH(0x1a17150)
C_FBH_RL cloneDummy_Notify 26 1 26 26.00 0 HASH(0x1937f60); HASH(0x1c29698)
PID_HKS_BD PID20_Set 19 1 19 19.00 0 HASH(0x194f848); PID_HKS_BD; desired; 20.0
eventTypes eventTypes_Notify 12 24 104 4.33 0 HASH(0x1383e98); HASH(0x18264e0)
FHEMWEB:192.168.2.103:49384 FW_Read 10 17 89 5.24 0 HASH(0x1c297b8)
FHEMWEB:192.168.2.103:49388 FW_Read 10 4 27 6.75 0 HASH(0x1c295f0)
FHEMWEB:192.168.2.103:49387 FW_Read 8 5 29 5.80 0 HASH(0x1c09ec8)
SSP_LOG FileLog_Log 7 24 62 2.58 0 HASH(0x184af08); HASH(0x1c0a7b0)
tmr-HMLAN_KeepAlive keepAlive:HMLAN1 7 3 18 6.00 3 keepAlive:HMLAN1
FHEMWEB:192.168.2.103:49389 FW_Read 5 2 10 5.00 0 HASH(0x1c11ef0)
WEB FW_Read 5 9 33 3.67 0 HASH(0x11926c8)
Laut Logfile wurde fhem um 4:30 neu gestartet und die Systemzeit wurde um 13 Min zurückgestellt. Das hatte ich (anscheinend) schon öfter, da ich ständig um eben diese 13 Min. meine Systemuhr neu stellen muss. Hab mir deshalb auch schon einen Abgleich mit der Atomuhr in Braunschweig in mein rc.local geschriedeb. Der wird allerdings nur bei einem Reboot gemacht.
Log vom Neustart bis sich das System aufgehängt hat im Anhang (Log/graph).
Das Selbe heute Nacht (05.05., ca. 1:30Uhr) wieder (Log2/graph2). Allerdings über 20Min Zeitverschiebung.
Beide Male finden sich vor dem crash sehr Ähnliche Einträge
2014.05.04 04:30:05.642 5: HMLAN_Parse: HMLAN1 R:E261CBA stat:0000 t:02255705 d:FF r:FFB2 m:21 8470 261CBA 000000 009235
2014.05.04 04:30:05.644 5: HMLAN1 dispatch A0C218470261CBA000000009235::-78:HMLAN1
2014.05.05 01:38:15.693 5: HMLAN_Parse: HMLAN1 R:E262430 stat:0000 t:036A680A d:FF r:FFA3 m:23 865A 262430 000000 7CAB2F
2014.05.05 01:38:15.695 5: HMLAN1 dispatch A0C23865A2624300000007CAB2F::-93:HMLAN1
Der Unterschied ist, dass am 04.05. der WTS_KU, am 05.05. der WTS_FL abgefragt wurde?!
Moin dan1180,
Bei mir rennt der RPI Monitor seit Monaten ohne Probleme, und deutlich Performance schonender wie z.B. Sysmon. Ich kann das Problem also so nicht nachvollziehen.
Zum Thema Systemzeit schau Dir mal Diesen Tread an:
http://www.forum-raspberrypi.de/Thread-tutorial-aktuelle-uhrzeit-mit-braunschweig-abgleichen
Die Lösung von meigrafd gefällt mir recht gut.
Dafür, dass Dein Pi in der Wüste landet, kann es 1001 Gründe geben, und da Du noch an diversen anderen Stellen am basteln bist, kommen noch einmal 1001 Gründe dazu. Allerdings hat Dein Pi wenn er abgestürztist immer sehr lange gestanden. 4.5 von ca 4:30 - 9:45, 5.5 von ca. 1:45 - 8:45.
Ich würde ersteinmal versuchen das System stabil zu bekommen, und dann Stück für Stück zu erweitern. Damit kann man den Fehler am besten einkreisen.
Gruß Joachim
Hallo Joachim,
diesesmal bist du es der schlampig gelesen hat ;)
Den Abgleich mit der Atomuhr mach ich schon. Allerdings greift der ja nur bei einem Reboot des RPi. Wenn sich meine Systemzeit aber auf einmal verändert bringt mir das auch nichts.
Zitat...und da Du noch an diversen anderen Stellen am basteln bist, kommen noch einmal 1001 Gründe dazu.
Das ist es ja was mich wundert...ich war fertig mit basteln.Soll heißen ich hab bis zur Installation von RPI Monitor fast ne Woche nichts mehr verändert und hatte die Probleme nicht?
ZitatAllerdings hat Dein Pi wenn er abgestürztist immer sehr lange gestanden
Na logisch.Wenn der um 1:30Uhr in die Knie geht bekomm ich das leider erst mit wenn ich nach dem Frühstück nachschau wie es in meinem Kessel ausschaut...
Aber wenn du denkst, dass das nicht am Monitoring liegt und in meinen Logfiles auch nichts verdächtiges steht dann gehört das wohl in ein anderes Forum...
Eine Frage noch: Was sagst du zur Systemauslastung?
Moin dan1180,
Zitatdiesesmal bist du es der schlampig gelesen hat
nicht wirklich, da die von mir vorgeschlagene Variante alle 2 Stunden einen Zeitabgleich macht, und nicht nur beim Systemstart.
Zitat
Sinnvoller wäre das über crontab des root Benutzers zu regeln:
Falls ihr als " pi " angemeldet seid, führt ihr bitte den Befehl sudo crontab -e aus
Wenn ihr direkt als " root " angemeldet seid, führt ihr bitte den Befehl crontab -e aus
Und tragt dort folgende Zeilen ein:
Code: Alles markieren
@reboot ntpdate -s 0.pool.ntp.org
0 */2 * * * ntpdate -s 0.pool.ntp.org
(-s steht für silent, wenn ihr also den Befehl über die Konsole testen wollt dann lasst -s weg)
Damit würde ein mal bei System Start und alle 2 Stunden ein Zeitabgleich gemacht werden
Wenn die Abstürze erst mit der Installation des RPI-Monitors aufgetreten sind, dann entferne ihn und beobachte, ob das System wieder stabil ist!
Bei mir rennt der RPI-Monitor seit Monaten sauber und fehlerfrei, es kann natürlich sein, dass das bei Dir nicht so ist, deshalb ausprobieren.
Die Systemlast sieht für 2 FHEM-Installationen gut aus, Vereinfacht gesagt hast Du ca. 25% Systemlast, da ist also noch viel Luft nach oben.
Gruß Joachim
Hallo Joachim,
mein System läuft nun seit dieser Woche stabil durch. Seit dem zweiten crash passt alles (vielleicht Startschwierigkeiten?).
Zitatnicht wirklich, da die von mir vorgeschlagene Variante alle 2 Stunden einen Zeitabgleich macht, und nicht nur beim Systemstart.
Dann will ich mich hier in aller Form entschuldigen ;D Trotzdem würde mich die Ursache dafür interessieren, da die verstellte Uhr auch ohne Systemcrash schon ab und an vorkam...
Also wenn meine apptimes und meine Systemlast gut sind dann kann ich diesen Beitrag, denke ich , als geslöst markieren und schließen?! :)
Moin dan1180,
ich glaube auch, dass Du dieses Thema: OWTHERM blockiert FHEM
auf gelöst setzen kannst.
Gruß Joachim
Und wieder ist ein Problem gelöst. Um mein fhem wieder salonfähig zu machen und vor allem um die HM Komponenten nicht auszubremsen habe ich meine OWX Komponenten, genauer gesagt meine 1wire Sensoren, wie von Joachim empfohlen in eine zweite fhem-Instanz ausgelagert. Seit dem rennt mein fhem wie ein junger Hund und aussteigende HM Komponenten gehören der Vergangenheit an.
Eine kleine Beschreibung wie das funktioniert findet ihr ab Antwort #66.
Vielen Dank an alle, die mir mit prouktioven Antworten versucht haben zu helfen und vor allem (mal wieder) an Joachim für die Lösung.
Bis bald (soll keine Drohung sein ;) )
Daniel