OWX Next Generation

Begonnen von Prof. Dr. Peter Henning, 09 November 2016, 20:48:30

Vorheriges Thema - Nächstes Thema

netlars

Hallo,

mir fliegt OWX Firmata um die Ohren.
Ich nutze einen Arduino Nano mit Firmata als Master. Der 1-wire Bus hängt an Pin 14.
Seit dem Update wählt er automatisch Pin 9.
Mir scheint als übernimmt er aus der Definition die 14 nicht.
Kann das sein?

MfG

Prof. Dr. Peter Henning

#436
Ups, da habe ich tatsächlich einen Fehler eingebaut. Wird sofort eingecheckt, für ganz dringende Fälle bitte die anhängende Version 7.02 von OWX_FRM verwenden.

LG

pah

UweH

OK, heute nach einem Update passt es.
Das Logfile ist verdächtig still...  ;)

Gruß
Uwe

cberl

Hallo,

ich habe mehrere Firmata mit OWX über Ethernet in Betrieb. Da fehlt mir noch das attr IODEV.
Oder hat sich da was an dem Handling geändert?

Bye Chris
Fhem immer aktuell @win2016 und @ubuntu VM|7xFRM/ArduinoEthernet|Homematic|HMLan|CUNO|HarmonyHub|Modbus|Z-Wave|Milight-Hub|MQTT|OWX an ETH-UART|GoogleAssist,Alexa,Sonos|2nHelios IP Vario|Amad-Odroid|Telegram|Enigma2

Maista

#439
Hallo PAH,

ich habe es gerade aktiviert. Dann kam natürlich die Fehlermeldung wegen dem PIN9 an Firmata.
Du hast das 11_OWX_FRM.pm nachgeschoben. Ich hatte das dann auf den RPI kopiert und dann scheinbar nur SHUTDOWN eingegeben.
FHEM lief dann nicht mehr hoch.
Hab dann in der Console FHEM mit Debug gestartet. Hier wurde dann angezeigt das  bei "$msg" was nicht stimmt.



sub Init() {
  my ($self) = @_;
  my $hash   = $self->{hash};
  my $dev    = $hash->{DeviceName};
  my $name   = $hash->{NAME};
  my $pin    = $hash->{pin}
  my $msg;


In der zweit letzten Zeile fehlt das Semikolon hinter dem " my $pin    = $hash->{pin}" !

Gruss Gerd

netlars

#440
Mmh,

das Simikolon fehlt wirklich,
leider knallt es immer noch, siehe Screenshot im Anhang

Das Attribut IODev fehlt.

MfG
Lars

C0mmanda

#441
Habe mit Firmata auch ein Problem.

Hatte eigentlich Pin7 belegt, hier will das Modul keine Devices finden.
Auf Pin 9 umgesteckt und es geht.

Wenn ich "get devices" anstosse werden die Sensoren gefunden.
Leider werden diese aber nichts ans Device weitergereicht.

Im genauen geht es um DS2411 die ich als Fenstersensoren nutze.
"get Devices" findet die Sensoren, das device selbst bleibt jedoch auf absent.

Im Log ist nur dieses zu finden:

2017.10.30 20:11:02 3: OWX_Verify called while interface OWX7 not opened
2017.10.30 20:11:02 3: OWX_Verify called while interface OWX7 not opened
2017.10.30 20:11:02 3: OWX_Verify called while interface OWX7 not opened
2017.10.30 20:11:02 3: OWX_Verify called while interface OWX7 not opened
2017.10.30 20:11:02 3: OWX_Verify called while interface OWX7 not opened
2017.10.30 20:11:02 3: OWX_Verify called while interface OWX7 not opened
2017.10.30 20:11:03 3: OWX_Verify called while interface OWX7 not opened


Alle Module sind in der aktuellsten Version vorhanden. (7.01).

grtz

Prof. Dr. Peter Henning

Sorry, bei dieser sehr schnellen Korrektur habe ich mich selbst aufs Kreuz gelegt - anbei die korrigierte Version, die den Pin richtig an das FRM-Modul weitergibt. IODev ist kein Attribut, sondern ein Internal.

LG

pah

C0mmanda

#443
Zitat von: Prof. Dr. Peter Henning am 31 Oktober 2017, 07:11:02
Sorry, bei dieser sehr schnellen Korrektur habe ich mich selbst aufs Kreuz gelegt - anbei die korrigierte Version, die den Pin richtig an das FRM-Modul weitergibt. IODev ist kein Attribut, sondern ein Internal.

LG

pah

Danke für die schnelle Hilfe.
Leider bleibt mein Problem bestehen.

Bus auf Pin7: Es werden keine Devices gefunden.
Bus auf Pin9: Es werden Devices gefunden.

Das ist erstmal kein Problem für mich.


Der Bus bleibt jedoch auf "initialized" und wechselt nicht nach "opened" und obwohl eine Bussuche (get devices) am BM Devices findet werden diese nicht an die Devices weitergegeben. Die Devices bleiben auf "present 0".
Siehe Screenshots.

Logeinträge bleiben auch:

2017.10.31 08:10:15 3: OWX_Verify called while interface OWX7 not opened
2017.10.31 08:10:18 3: OWX_Verify called while interface OWX7 not opened
2017.10.31 08:10:18 3: OWX_Verify called while interface OWX7 not opened
2017.10.31 08:10:18 3: OWX_Verify called while interface OWX7 not opened
2017.10.31 08:10:18 3: OWX_Verify called while interface OWX7 not opened
2017.10.31 08:10:18 3: OWX_Verify called while interface OWX7 not opened
2017.10.31 08:10:18 3: OWX_Verify called while interface OWX7 not opened
2017.10.31 08:10:18 3: OWX_Verify called while interface OWX7 not opened



grtz
CmdA

netlars

Danke für die Korrekturen,

bei mir übernimmt er jetzt PIN14 vom Firmata. Sensoren werden auch ausgelesen.

Das Attribut IODev ist aber dennoch von nöten, in dem alten OWX Modul konnte man mittels den Attribut das entsprechende Firmata Device wählen, wenn man mehrere davon in seiner Konfiguration einsetzt. Momentan sehe ich keinen Weg, das Device zu wechseln bzw. zuzuordnen.

Getestet habe ich die oben angehängte V7.03.

MfG
Lars

Bartimaus

Moin,

gestern abend noch "aus versehen" in FHEM auf den Button "UpdateAll" statt "Update" geklickt. Dabei wurden dann auch die 1wire-Module (21_OWAD.pm 21_OWMULTI.pm 21_OWCOUNT.pm 21_OWSWITCH.pm 21_OWTHERM.pm 11_OWDevice.pm 00_OWX.pm) aktualisiert, die ich eigentlich per "exclude_from_update" ausgeschlossen hatte. Aber siehe da, alles funktioniert jetzt tadellos auch mit OWX_ASYNC...... just my 2cents
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

Frank_Huber

#446
Erste Auffälligkeit:
Bei OWTHERM wird scheinbar das Attribut tempLow gelegentlich auf default gesetzt.
Hatte die TL schon mehrfach auf -20 gestellt aber es geht immer wieder zurück.

Zweite Auffälligkeit:
Nach einem Neustart des Systems haben die OWTHERM öfters/immer wieder einen falschen Wert von 85 Grad.
Das war mit den "alten" Versionen und bei meinen 4 Produktiven Instanzen nie passiert.

Bartimaus

Zitat von: Frank_Huber am 31 Oktober 2017, 15:13:34
Zweite Auffälligkeit:
Nach einem Neustart des Systems haben die OWTHERM immer wieder einen falschen Wert von 85 Grad.
Das war mit den "alten" Versionen nie passiert.

Kann ich mit meiner Konstellation so nicht bestätigen. Bei 2 Sensoren war dem gestern Abend zwar auch so, lag aber letztendlich an einer korridierten Leitung (Poolsensor). Habe ich gerade behoben, jetzt wieder alles gut. Ich nutzte jedoch OWX_ASYNC statt OWX
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

Frank_Huber

Verkabelung kann ich ausschließen, es ist meine Test-Instanz. Die hat nach dem Busmaster nur ca 15cm Drähte zu den Sensoren.
Hab aktuell 2 x Temp/Feuchte-Sensoren von TM3D.de dran.

Busmaster:
Internals:
   ALARMED    no
   ASYNCHRONOUS 1
   BUSY       0
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE002xu-if00-port0
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_DAE002xu-if00-port0
   FD         5
   INITDONE   1
   INTERFACE  DS2480
   LASTSEND   1509459583.03181
   NAME       1wire
   NEXT_OPEN  1509459101
   NR         55
   PARTIAL
   PRESENT    1
   ROM_ID     FF
   STATE      opened
   TYPE       OWX
   interval   300
   timeout    2
   version    7.01
   DEVHASH:
     1wire      Busmaster
     OWX_26_3D8780010000 26.3D8780010000.2E
     OWX_26_F6752B010000 26.F6752B010000.51
     OWX_28_B10A5F070000 28.B10A5F070000.AB
     OWX_28_BD3E60070000 28.BD3E60070000.9F
   DEVS:
     28.B10A5F070000.AB
     28.BD3E60070000.9F
     26.F6752B010000.51
     26.3D8780010000.2E
   QUEUE:
   READINGS:
     2017-10-31 15:19:41   queue           14
     2017-10-31 15:10:41   state           opened
Attributes:
   DbLogExclude .*
   asynchronous 1
   group      System-Hardware
   interval   300
   room       OWX
   verbose    0


OWTHERM Sensor:
Internals:
   ALARM      0
   ASYNC      0
   DEF        DS18B20 B10A5F070000
   ERRCOUNT   0
   INTERVAL   300
   IODev      1wire
   NAME       OWX_28_B10A5F070000
   NOTIFYDEV  global
   NR         56
   NTFY_ORDER 50-OWX_28_B10A5F070000
   OW_FAMILY  28
   OW_ID      B10A5F070000
   PRESENT    1
   ROM_ID     28.B10A5F070000.AB
   STATE      T: 25.69 °C
   TYPE       OWTHERM
   owg_temp   25.6875
   owg_th     75
   owg_tl     -20
   Helper:
     DBLOG:
       data:
         logdb:
           TIME       1509459583.15503
           VALUE      state: T: 25.69 °C
       state:
         logdb:
           TIME       1509458980.11526
           VALUE      initialized
       temperature:
         logdb:
           TIME       1509459583.15503
           VALUE      25.6875
   READINGS:
     2017-10-31 15:19:43   state           T: 25.69 °C
     2017-10-31 15:19:43   temperature     25.6875
   tempf:
     factor     1
     offset     0
Attributes:
   IODev      1wire
   model      DS18B20
   room       OWX
   tempHigh   75
   tempLow    -20

Prof. Dr. Peter Henning

#449
Zum Firmata mit mehreren Arduinos: das muss ich mal versuchen nachzustellen.
Allerdings hält sich mein Mitleid in Grenzen - als ich nämlich nach Testern für das neue Firmata-Interface gesucht habe, war gähnende Leere. Habe ich mir also selber eins eingerichtet, fein, aber eben nur Eines.  Ich bin dran, kann aber eine Lösung heute noch nicht versprechen.

@netlars:
Zitat
Das Attribut IODev ist aber dennoch von nöten, in dem alten OWX Modul konnte man mittels den Attribut das entsprechende Firmata Device wählen, wenn man mehrere davon in seiner Konfiguration einsetzt. Momentan sehe ich keinen Weg, das Device zu wechseln bzw. zuzuordnen.
. Sorry, das ist Unsinn. Bei der Definition eines OWX-Firmata-Interface wird das IODev in der Definition angegeben - das ist ein Internal, kein Attribut. Und zum Wechseln muss man nur ein defmod absetzen. Bei den Frontenddevices ist das Attribut vorhanden, wird aber in der Regel nach einer Bussuche überschrieben.

@Frank Huber:
Zitathaben die OWTHERM immer wieder einen falschen Wert
kann ich nicht glauben. Wenn nämlich irgendetwas mit den zurückgelieferten Daten nicht stimmt, wird im Log ein Fehler angezeigt und der Wert gar nicht übernommen. Also bitte die fehlermeldungen aus dem Log posten.

LG

pah