Anregungen/Tipps für universelle Einbindung von DS2438 an wiregated

[Robert]

Hi!

Ausgehend von der Sammelbestellung von DS2438 basierten Luftfeuchtesensoren (https://knx-user-forum.de/diy-do-you...chtigkeit.html) hat mich das momentane Konzept der Einbindung von DS2438-basierten Sensoren am owfs/wiregated gestört: Die Sensoren werden alle anhand einer ID in ihrem EEPROM "erkannt" und dann werden fixe Formeln ausgerechnet. Blöd, wenn man z.B. einen anderen als den vorgesehenen Lichtsensor einsetzen will oder gar irgendwelche Ultraschallsensoren, Druckmesser oder ähnliches auslesen will. Das ginge dann zwar über "Plugins" - allerdings finde ich das nicht so übersichtlich.

Daher: Ein Patch, der edit_owsensorconf.cgi, save_owsensorconf.cgi und wiregated-ow.pl betrifft, und alle nicht per ID markierten DS2438 als "Universal-Sensor" einbindet. Alle relevanten Messgrößen des Sensors (VDD, VAD, vis und Temperatur) werden automatisch ausgelesen und können dann per Webmin-Oberfläche zur Berechnung von Endwerten benutzt werden (per eval). Dabei kann auch per Hash auf vorherige Berechnungen zurückgegriffen werden (siehe Screenshot). Somit können eigene Sensoren mit bisher nicht unterstützter Kennlinie schnell eingebunden werden. Ebenfalls können so natürlich auch schnell mal Schwellwerte geprüft werden ohne das es weiterer Logik bedarf...

Die Idee ist momentan noch in der Findungsphase - mich würde interessieren ob das überhaupt wer braucht - sonst hack ich mir das so da rein. Auch würde ich mich über Feedback von Perl-Cracks freuen, wie man die Formeln a) benutzerfreundlicher macht b) sicherer macht hinsichtlich Syntaxfehlern etc. Und es müsste mal drüber gesprochen werden, wie das ganze in der Webmin-Oberfläche angezeigt wird... Momentan verwende ich für die Formeln (und abhängige Daten wie Cycle und GA) ein Array von Hashes (@{ $conf{$Schluessel}{'items'} }). Da wäre es cool, wenn da die Länge nicht fix wäre, sondern sich automatisch immer um einen "Leereintrag" ergänzen würde, so dass man einen neuen Sensor Formel um Formel befüllen könnte.

Grüße
Robert

[JuMi2006]

Also ich fände es sinnvoll. Der wiregated läuft eh und man könnte sich einiges an externer Logik/Plugins sparen. Vor allem die Eingabe von Kennlinien/Faktoren würde einige weitere Schnittstellen eröffnen.

Mithelfen kann ich da aber leider nicht ... meine Perl Basics würden da nicht mehr reichen. Für Formeln könnte man ja die Variablen A,B,C,D etc. verwenden. evtl. benötigt es dann einen Check ob z.B. C=defined und dann wird eben D eingeblendet. Wie das gehen soll hab ich aber auch keine Ahnung. im rrdtool werden ja solche Formeln auch als rpn-expression verwendet.

Gruß

[greentux]

Robert, im Moment wird es wohl so gemacht, das das schon im owfs abgefrühstückt wird. Dort sind die AMS reingepatched und die Berechnung findet dort statt, so dass die richtigen Werte gleich im owfs zu finden sind.

Du willst jetzt die Rohwerte hochgeben und dann die endgültigen Ergebnisse in Perl berechnen?

[Robert]

Ja, genau.

Es ist in meinen Augen Irrsinn, für jeden möglichen Sensor die Kennlinie im owfs abzulegen. Man stelle sich das mal für verschiedene Helligkeitssensoren vor (SFH203P oder eben SFH5711 oder oder). Das der HIH4030 & Co drin sind, ist der Tatsache geschuldet, dass es da nicht so viel Auswahl gibt und zudem Maxim seinerzeit eine entsprechende App-Note herausgegeben hat.

Im owfs sind auch nicht die AMS, sondern scheinbar welche von iButtonLink?

Klar, kein Problem einen DS2438 zum MS-TH zu machen:
owwrite --hex 26.xxxxxxxxx/pages/page.3 19
dann evtl. noch
owwrite 26.xxxxxxxxx/CA 0

ich finde jedoch die andere Version schöner - zumal ja sonst kein vernünftiger Helligkeitssensor funktioniert... Man könnte halt "alle" Sensoren an den DS2438 anschließen... Du hast eine Ultraschall-Baugruppe - per Spannung eingelesen, Formel in den Webmin - fertig. Nix Daemon-patchen... Neuer Helligkeitssensor - Kennlinie annähern, Webmin - fertig... usw...

Grüße
Robert

[greentux]

Irrsinn ist aber auch, dann in allen Frameworks die Umrechnungen einzubauen.
- smarthome.py
- wg (nur als plugin möglich)

Webmin würde ich da noch nichtmal präferieren. wenn das erstmal im plugin geht, wärs ein Anfang.
Aus meiner Sicht gehört das in die Lib, wo es jetzt ist.

[luigi4711]

Sehe ich auch so... jeden möglichen Sensortyp (was am Ende wohl doch eine recht übersichtliche Zahl ist) einmal in den Basics einbauen, statt bei jedem Deployment eines Sensors den Anwender damit zu 'belasten' halte ich für den besseren Weg.
Das hier vorgeschlagene Feature im Webif klingt eher nach einem Feature für Entwickler, die die nächste Reihe von Prototypen schon auf der Wertkbank liegen haben.
Ist auch wichtig, aber ich denke nicht so Anwender relevant.

luigi

[gdfde]

Hi!

Die Idee ist momentan noch in der Findungsphase - mich würde interessieren ob das überhaupt wer braucht - sonst hack ich mir das so da rein.

Hi Robert,

ich würde genau das benötigen, was du beschrieben hast.

Ich hab den Luftgütesensor von eservice, der Temperatur, Luftfeuchte und Luftgüte (anscheinend am 8. Pin vom DS2438) zurückgibt.

Wiregate/CG erkennt den automatisch als MS-TH Sensor...soweit so gut.
Die Luftgüte wird mit der vis Spannung ausgegeben, aber ich bekomm das nicht auf den KNX Bus bzw. im wiregate/CG abgebildet.

Also workaround greif ich nun von IP-SYmcon mittels der ownet.php die vis ab und rechne mir dort den VOC Wert aus.

Leider taugt das dem owserver am CG nicht sonderlich, der bleibt ca. 1 mal pro Tag stehen mit dieser Meldung:

Feb 10 09:40:42 wiregate kernel: [48672.720976] owserver      D d004e12f     0  2124      1
Feb 10 09:40:42 wiregate kernel: [48672.720997]        ce136ed0 00000082 cf1e38ec d004e12f cf1e3800 2f700000 ce13705c cf21a020 
Feb 10 09:40:42 wiregate kernel: [48672.721033]        00000000 7fffffff cf1b8400 b750b264 ffffffff c02a6ae3 d003be2c cec69800 
Feb 10 09:40:42 wiregate kernel: [48672.721068]        cec69ba0 0001fc00 00000000 00000046 00000046 00000046 00000286 00000282 
Feb 10 09:40:42 wiregate kernel: [48672.721102] Call Trace:
Feb 10 09:40:42 wiregate kernel: [48672.721138]  [<d004e12f>] start_ed_unlink+0x11/0x49 [ohci_hcd]
Feb 10 09:40:42 wiregate kernel: [48672.721202]  [<c02a6ae3>] schedule_timeout+0x13/0x86
Feb 10 09:40:42 wiregate kernel: [48672.721238]  [<d003be2c>] rhine_interrupt+0x5a2/0x5fd [via_rhine]
Feb 10 09:40:42 wiregate kernel: [48672.721312]  [<c02a70b0>] __down+0x4a/0x70
Feb 10 09:40:42 wiregate kernel: [48672.721348]  [<c012cb4b>] down+0x2b/0x39
Feb 10 09:40:42 wiregate kernel: [48672.721380]  [<d088c12b>] usbdev_ioctl+0x37/0x1104 [usbcore]
Feb 10 09:40:42 wiregate kernel: [48672.721549]  [<c017344a>] dput+0x15/0xac
Feb 10 09:40:42 wiregate kernel: [48672.721578]  [<c016d80c>] __link_path_walk+0xa0b/0xa26
Feb 10 09:40:42 wiregate kernel: [48672.721615]  [<c0226eb6>] klist_devices_put+0x0/0x8
Feb 10 09:40:42 wiregate kernel: [48672.721646]  [<c02a1598>] klist_del+0x10/0x1f
Feb 10 09:40:42 wiregate kernel: [48672.721672]  [<c02a15b6>] klist_iter_exit+0xf/0x18
Feb 10 09:40:42 wiregate kernel: [48672.721696]  [<c0227271>] bus_find_device+0x59/0x63
Feb 10 09:40:42 wiregate kernel: [48672.721729]  [<c01ca8df>] kobject_get+0xf/0x13
Feb 10 09:40:42 wiregate kernel: [48672.721775]  [<c0225d8d>] get_device+0xe/0x14
Feb 10 09:40:42 wiregate kernel: [48672.721800]  [<d08812a0>] usb_get_dev+0xf/0x13 [usbcore]
Feb 10 09:40:42 wiregate kernel: [48672.721883]  [<c01a8dfb>] security_task_getsecid+0xc/0xd
Feb 10 09:40:42 wiregate kernel: [48672.721913]  [<d088be3b>] usbdev_open+0x13e/0x146 [usbcore]
Feb 10 09:40:42 wiregate kernel: [48672.722018]  [<c0167da0>] chrdev_open+0xc1/0xf6
Feb 10 09:40:42 wiregate kernel: [48672.722054]  [<c0167cdf>] chrdev_open+0x0/0xf6
Feb 10 09:40:42 wiregate kernel: [48672.722076]  [<c01647ee>] __dentry_open+0x11f/0x1e7
Feb 10 09:40:42 wiregate kernel: [48672.722113]  [<c01648d2>] nameidata_to_filp+0x1c/0x2c
Feb 10 09:40:42 wiregate kernel: [48672.722145]  [<c016e865>] do_filp_open+0x33d/0x648
Feb 10 09:40:42 wiregate kernel: [48672.722191]  [<c016f93e>] filldir+0x79/0xb9
Feb 10 09:40:42 wiregate kernel: [48672.722227]  [<c017c18e>] dcache_readdir+0x12c/0x170
Feb 10 09:40:42 wiregate kernel: [48672.722278]  [<d088c0f4>] usbdev_ioctl+0x0/0x1104 [usbcore]
Feb 10 09:40:42 wiregate kernel: [48672.722376]  [<c016f5a2>] vfs_ioctl+0x3a/0x49
Feb 10 09:40:42 wiregate kernel: [48672.722405]  [<c016f794>] do_vfs_ioctl+0x1e3/0x1f6
Feb 10 09:40:42 wiregate kernel: [48672.722432]  [<c0164661>] do_sys_open+0xae/0xb6
Feb 10 09:40:42 wiregate kernel: [48672.722463]  [<c016f7e8>] sys_ioctl+0x41/0x59
Feb 10 09:40:42 wiregate kernel: [48672.722496]  [<c01037c2>] syscall_call+0x7/0xb
Feb 10 09:40:42 wiregate kernel: [48672.722562]  =======================

d.h. mir würds schon reichen, einfach nur die vis Werte aufn KNX Bus zu bekommen.

Wie hast du das jetzt gemacht, den "Universal 2438" an den Bus zu bringen?

[greentux]

Dann kannst Du probieren, den Sensor zum THS zu machen. Anschliessend steht dir die Spannung zur Verfügung.
Das wäre jetzt nicht so schwer.

Robert, generell schlage ich vor, wenn schon im Applicationlayer, dann aber nicht auch noch von dem Webmin abhängig machen.
Also im wiregated schon, aber config halt in der owsensors.conf.

[gdfde]

@greentux

Funktioniert leider nicht.
Wenn man ihn zum THS macht, wird gleich der Lux Wert ausgerechnet und im Webmin/am Bus ausgegeben....aber nicht der vis Wert.

[greentux]

Sorry, einen 2438TV meinte ich natürlich.
Also Temp / Spannung.

[gdfde]

...

Das hab ich vorher schon probiert.
Als 2438 TV gibt er nur die VAD zurück.
Ich bräuchte aber die vis zur Berechnung der Luftgüte.

[greentux]

Dann musst Du Dir das selber erweitern.
Perlkenntnisse vorrausgesetzt

[greentux]

Roberts Variante wäre dann die "Perllose"

[gdfde]

Da ich mit perl und sonstigen Programmiersprachen eher auf Kriegsfuß stehe, wäre mir Robert´s Variante lieber

Vielleicht meldet er sich ja noch

[Robert]

Hi!

Ich habe an der Stelle nicht weiterentwickelt, da das Feedback recht uneins war und meine Perl-Kenntnisse (die es braucht) auch sehr beschränkt sind. Die Sourcen kann ich versuchen aus meinem Webmin rauszuschnippeln!

Grüße
Robert