Das ist jetzt zwar ein Cross-post aus dem Firmata+Arduino thread, aber weil es ja alle OWX-nutzer betrifft ist es doch besser hier aufgehoben:
In den nächsten Tagen gibt es ein kleineres Update der OWX-Module die beim Reconnect bzw. Restart noch ein paar Details feinschleifen. Kommt aber erst in den Trunk, wenn alles auf Herz und Nieren getestet ist.
Geändert habe ich:
- Setzen der Statuswerte beim Neustart gefixed (alle Devices, bisher gabs immer Mecker 'define Device ... first').
- Device-discovery (incl. Autocreate) auch bei verzögertem Connect (FRM, alle OW-Devices).
- Device-spezifisches Interval jetzt auch per Attribut 'interval' (alle Devices). Das Attribut überlebt im Gegensatz zum 'set xxx interval 123' auch einen Restart ;-)
- Neues Attribute 'resolution' für den DS18x20 (9-12 Bit, 12 Bit default. Bei niedrigerer Auflösung geht die Messung schneller, geht mit OWX und OWServer).
- Initialisierung des OWTHERM-devices erst nach Auslesen der Configuration aus dem DS18x20 (sonst überschreiben die Default-werte die im Baustein ggf. schon gespeicherte Config - auch OWX und OWServer).
Wer mittesten will (bitte bitte, nicht dass ich irgendwas übersehe oder mit meinem begrenzten Test-equipment gar nicht finden kann) läd sich die betreffenden OWX-module (FRM-nutzer bitte auch das FRM-modul) hier von GitHub (https://github.com/ntruchsess/fhem-mirror/tree/refactoring_owtherm/fhem/FHEM/) oder dasselbe auch als zip-file (https://github.com/ntruchsess/fhem-mirror/archive/refactoring_owtherm.zip)herunter.
Ich teste selber mit: FRM über USB und Ethernet, DS2482-Busmaster über FTDI-USB-adapter und OWServer auf Raspberry Pi.
Gruß,
Norbert
grade einen fix für den 'Argument "" isn't numeric'-Fehler im OWCOUNT nachgeschoben.
hm... irgendwie scheint das niemanden hier zu interessieren. Wenn es bis zum Wochenende kein Feedback gibt, dann werde ich die Änderungen halt nur von mir selbst getestet ins SVN committen.
- Norbert
Mich interessiert es brenndend, kann aber aufgrund räumlicher Entfernung nicht testen. :(
Ich leide schon seit ca. einem Jahr an dem Reconnect Problem....
Hallo Norbert,
nicht traurig sein, das scheinbare Dessinteresse kommt zu mindest bei mir von einer neuen beruflichen Megaaufgabe, daher auch noch keine weiteren Versuche bei der Firmata über Netzwerk etc. Da kommen auch wieder ruhigere Zeiten und es wird eifriger getestet. Wenn Du es einstellst, so das es über update verteilt wird werde ich automatisch mit testen und hoffe dass es läuft. :) ;D ;D
ach - traurig macht mich das nicht ;)
Ich bin da halt etwas zurückhaltend. Die OWX-Module sind ja relativ stabil und seit April ohne wesentliche Änderungen bei einigen am laufen. Da will ich natürlich nicht ohne Vorwarnung Changes verteilen, zumal ich ja auch nicht der ursprüngliche Autor bin. Peter Henning hat halt seit Monaten wenig oder keine Zeit für das Thema und ich bin jetzt mal wieder dran am werkeln. Beim Arbeiten am asynchronen OWX bin ich halt über einige Ungereimtheiten gestolpert, die ich erst mal in der stabilen Version ausbügele - wenn ich das alles nur im Asynchronen Branch machen würde, dann kommen einfach zu viele Changes auf einmal rein und man kann gar nicht mehr wissen, ob irgendwas am asynchronen Refactoring oder am bestehenden Code liegt.
Gruß,
Norbert
Hallo,
bei mir ist OWX derzeit auch recht stabil, seit der Adapter nicht mehr am Hub hängt.
Change never ....
Aber ich könnte in den nächsten Tagen schon mal versuchen
Bernhard
Hallo,
wann gehen die OWX Fixes live?
Habe seit neuestem auch die Meldung:
Argument "" isn't numeric in numeric lt (<) at /usr/share/fhem/FHEM/21_OWTHERM.pm line 953.
Weiters zickt das 1-Wire oft nach einem Kaltstart meiner Tuxradio box ... shutdown restart machts dann wieder gut aber eher gefährlich bei Stromausfällen.
Danke und schöne grüße aus Wien,
Thomas
Thomas, sei so gut und installiere das Update manuell (link siehe ersten Post) und sage uns, ob es auf Deinem Tux-Radio alles funktioniert. Das würde das 'live-gehen' sehr beschleunigen ;-)
- Norbert
Hallo Norbert,
einfach alle 21_OW*.pm runterladen, mit WinSCP überschreiben, neustarten und schauen was passiert - oder?
Grüße Thomas
ja, dazu noch 00_OWX.pm und - sofern Du einen Arduino als Busmaster verwendest - 10_FRM.pm. In letzterem Fall vorher FHEM noch per update aktualisieren um die perl-firmata auch auf einem aktuellen Stand zu haben.
Gruß,
Norbert
Hallo Norbert,
hab das jetzt getestet.
Der "Argument "" isn't numeric in numeric lt (<) at /usr/share/fhem/FHEM/21_OWTHERM.pm line 953." Fehler ist weg - zumindest bis jetzt noch nicht aufgetreten.
Das Thema mit dem Kaltstart (Strom weg und wieder dran) ist jedoch immer noch da.
Bekomme zuerst ca. 4 Minuten lang die Meldung:
2013.11.08 16:53:44.403 1: OWX: 1-Wire bus OneWire: interface not detected, answer was
und am Ende der 4 Minuten:
2013.11.08 16:53:44.787 3: OWTHERM: Device T_Aussen_OW defined.
2013.11.08 16:53:45.121 3: OWID: Device OWX_01_805973140000 defined.
2013.11.08 16:53:45.319 1: Including /var/log/fhem/fhem.save
2013.11.08 16:53:46.434 1: usb create starting
2013.11.08 16:53:50.481 1: usb create end
2013.11.08 16:53:50.498 0: Server started with 66 defined entities (version $Id: fhem.pl 4099 2013-10-22 20:55:35Z rudolfkoenig $, os linux, user fhem, pid 1025)
2013.11.08 16:53:55.836 3: OWX: Reset called with undefined interface
2013.11.08 16:53:55.838 3: OWX: Complex called with undefined interface
Dann bis zum "shutdown restart" bei jedem Intervall:
2013.11.08 17:08:55.021 3: OWX: Reset called with undefined interface
2013.11.08 17:08:55.023 3: OWX: Complex called with undefined interface
Der OWX hat den Status not present.
Nach dem Restart schaut das Logfile so aus:
2013.11.08 17:16:43.721 3: telnetPort: port 7072 opened
2013.11.08 17:16:50.289 3: Opening OneWire device /dev/ttyUSB0
2013.11.08 17:16:50.305 3: Setting OneWire baudrate to 9600
2013.11.08 17:16:50.362 3: OneWire device opened
2013.11.08 17:16:50.364 1: OWX: Serial device /dev/ttyUSB0 defined
2013.11.08 17:16:50.547 1: OWX: 1-Wire bus OneWire: interface master DS2480 detected for the first time
2013.11.08 17:16:50.873 3: OWTHERM: Device T_Aussen_OW defined.
2013.11.08 17:16:51.089 3: OWID: Device OWX_01_805973140000 defined.
2013.11.08 17:16:51.143 1: Including /var/log/fhem/fhem.save
2013.11.08 17:16:52.254 1: usb create starting
2013.11.08 17:16:56.247 1: usb create end
2013.11.08 17:16:56.279 0: Server started with 66 defined entities (version $Id: fhem.pl 4099 2013-10-22 20:55:35Z rudolfkoenig $, os linux, user fhem, pid 1044)
2013.11.08 17:17:03.803 1: OWX: 1-Wire devices found on bus OneWire (T_Aussen_OW,OWX_01_805973140000)
und OWTHERM liefert schön die Aussentemperatur.
Hast du hierzu noch eine Idee?
Grüße Thomas
hm merkwürdig. Wie sieht es denn aus, wenn Du fhem nicht automatisch mit hochfährst, sondern ein bischen später (von Hand) startest?
Hallo Leute,
nach einer Phase extremer beruflicher Belastung bin ich wieder auf Deck und werde bei OWX wieder mitspielen.
LG
pah
Hallo Peteer, freut mich, dass Du wieder an Board bist.
Hast Du Zeit die in diesem Thread diskutierten Fixes mal anzusehen, oder soll ich die wie angekündigt committen?
Gruß,
Norbert
Hallo Norbert,
diese Woche wird es noch nichts, weil ich morgen volles Lehrprogramm habe und Mi-Fr nach London muss. Und der Sa ist auch schon wieder weg ...
LG
pah
Hallo @ all,
prima, dass Ihr hier weitermacht - auch wenn bei mir die Devices mit OWX schon seit Monaten auf dem Produktivsystem ohne Probleme laufen. Hab die geänderten Module heute eingespielt - keine Fehlermeldungen oder sonstige Auffälligkeiten.
Nur 2 kleine kosmetische Fragen - beim OWLCD fehlt noch die Änderung:
Zitatfix OWXxxx_Get that web-interface is able to parse the response
2013-10-18 12:08:37
und beim OWID hatte ich schon vor Monaten angefragt, ob "not present" nicht der Vereinheitlichung wegen in "absent" geändert werden kann. Vieleicht könnt Ihr Euch das ja noch mal überlegen, es würde nach jedem Update manuelle Nacharbeit ersparen.
Danke,
Danke fürs testen, dieOWLCD get-response habe ich grade eingepflegt. (https://github.com/ntruchsess/fhem-mirror/commit/830916a762fb6683fb6aecc317548a168819bf90)
Wg. dem 'not present' vs. 'absent' - mir ist das eigentlich ziemlich egal, im asynchronen Zweig habe ich das explizite Setzen des States eh entfernt und durch 'stateFormat' ersetzt, da kann das dann jeder selber definieren.
Mit was würde man vereinheitlichen, wenn 'absent' benutzt wird? Eine kurze Suche über díe FHEM-sourcen war nicht so aussagekräftig, oder beziehst Du Dich auf OWDevice?
Gruß,
Norbert
Hallo Norbert,
Danke, zu Deiner Frage - z.B. mit Presence - absent ist mMn einfach logischer, ich nutze es als Türkontakt so - eventMap present:zu absent:offen, das ging zumindest bisher mit not present nicht. So habe ich es bei jedem OWID Update an den 3 Stellen im Modul geändert.
Zitat von: Prof. Dr. Peter Henning am 10 November 2013, 18:02:07
diese Woche wird es noch nichts
kein Problem, so riesig sind die changes ja auch nicht. Hab's grade gemerged und eingecheckt.
Zitat von: det. am 10 November 2013, 19:52:38z.B. mit Presence[...]bei jedem OWID Update an den 3 Stellen im Modul geändert.
ich mach dazu mal einen nuen Thread auf um ein Meinungsbild einzuholen...
- Norbert