FRM & FHEM-Crash

ThoTo · 15 Dezember 2017, 15:35:16

Hallo zusammen!

Ich nutze seit zwei Monaten FRM und OWX um 1wire-Temperatursensoren in FHEM einzubinden.
Es kam jetzt schon einige Male vor, dass mir FHEM im Betrieb abgestürzt ist, das war vor der Nutzung von FRM nicht der Fall.
Laut Logs passierte der letzte Crash gegen 09:57 Uhr, der letzte Filelogeintrag der Sensoren war um 09:53 Uhr.

FHEM Log

Code Auswählen

2017.12.15 11:03:31 3: WEB: port 8083 opened
2017.12.15 11:03:31 3: telnetPort: port 7072 opened
pin '19' is not configured for mode 'ONEWIRE' at FHEM/lib/Device/Firmata/Platform.pm line 784.
2017.12.15 09:57:08 3: CUL_HM set OGBA.HM.Beleuchtung on-for-timer 125
2017.12.15 09:56:31 1: fhem_hw:2004 reappeared (OWArduino)
2017.12.15 09:56:30 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_06
2017.12.15 09:56:30 3: querying Firmata Firmware Version
2017.12.15 09:56:29 3: querying Firmata Firmware Version
2017.12.15 09:55:27 3: no response from Firmata, closing DevIO
2017.12.15 09:55:27 3: querying Firmata Firmware Version
2017.12.15 09:55:26 3: querying Firmata Firmware Version
2017.12.15 09:55:25 3: querying Firmata Firmware Version
2017.12.15 09:55:24 3: querying Firmata Firmware Version
2017.12.15 09:55:22 1: fhem_hw:2004 disconnected, waiting to reappear (OWArduino)
2017.12.15 09:55:21 1: fhem_hw:2004 disconnected, waiting to reappear (OWArduino)
2017.12.15 09:52:00 3: CUL_HM set OGBA.HM.Beleuchtung on
2017.12.15 09:50:24 3: CUL_HM set OGBA.HM.Beleuchtung on-for-timer 125
2017.12.15 09:48:22 3: CUL_HM set OGBA.HM.Beleuchtung on
2017.12.15 09:48:09 3: CUL_HM set OGBA.HM.Beleuchtung on-for-timer 125
2017.12.15 09:44:32 3: CUL_HM set OGBA.HM.Beleuchtung on
2017.12.15 09:44:22 3: CUL_HM set OGBA.HM.Beleuchtung on-for-timer 125
2017.12.15 09:41:00 3: CUL_HM set OGBA.HM.Beleuchtung on

list OWArduino

Code Auswählen

Internals:
   CFGFN      
   DEF        fhem_hw:2004
   DeviceName fhem_hw:2004
   FD         71
   NAME       OWArduino
   NOTIFYDEV  global
   NR         219
   NTFY_ORDER 50-OWArduino
   PARTIAL    
   STATE      Initialized
   TYPE       FRM
   analog_pins 14,15,16,17,18,19,20,21
   analog_resolutions 14:10,15:10,16:10,17:10,18:10,19:10,20:10,21:10
   encoder_pins 2,3
   encoder_resolutions 2:28,3:28
   firmware   ConfigurableFirmata.ino
   firmware_version V_2_06
   i2c_pins   18,19
   input_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
   onewire_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
   output_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
   pwm_pins   3,5,6,9,10,11
   pwm_resolutions 3:8,5:8,6:8,9:8,10:8,11:8
   servo_pins 2,3,4,5,6,7,8,9,10,11,12,13
   servo_resolutions 2:14,3:14,4:14,5:14,6:14,7:14,8:14,9:14,10:14,11:14,12:14,13:14
   stepper_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
   stepper_resolutions 2:21,3:21,4:21,5:21,6:21,7:21,8:21,9:21,10:21,11:21,12:21,13:21,14:21,15:21,16:21,17:21,18:21,19:21
   READINGS:
     2017-12-15 11:03:57   state           opened
Attributes:
   group      USB Dongle
   room       System

Der Arduino ist mittels Ser2Net am Host fhem_hw eingebunden:

Code Auswählen

2004:raw:0:/dev/fhem/onewire:57600 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE

Es scheint dass die Verbindung zu Ser2Net verloren geht bzw. der Arduino nicht mehr ansprechbar ist.
Nach einer Minute dürfte zumindest die Verbindung wiederaufgebaut sein, aber es folgt eben der für mich nicht erklärbare FHEM-Crash.

Woran könnte das liegen?

LG Thomas

ThoTo · 20 Dezember 2017, 15:55:51

Nachdem der Maintainer des Moduls zuletzt im Oktober 2016 online war, erwarte ich mir von ihm keine Rückmeldung.
Vielleicht bringt verbose 5 etwas, ich werde den Thread dann updaten:

Code Auswählen

pin '19' is not configured for mode 'ONEWIRE' at FHEM/lib/Device/Firmata/Platform.pm line 784.
2017.12.21 06:55:16 1: fhem_hw:2004 reappeared (OWArduino)
2017.12.21 06:55:16 5: SW: f07a6807f7
2017.12.21 06:55:16 5: FRM:>f07a6807f7
2017.12.21 06:55:16 5: FRM:<7f000101010308040e070108157f000101010308040e070108157f000101010308040e070108157f00010101040e070108157f00010101040e070108157f00010101020a070108157f00010101020a070108157f00010101020a070108157f00010101020a070108157f00010101020a0601070108157f00010101020a0601070108157f020a7f020a7ff7
2017.12.21 06:55:16 5: FRM:<010815091c7f00010101040e070108157f000101010308040e070108157f000101010308040e070108157f00010101040e070108157f00010101040e07010815
2017.12.21 06:55:16 5: FRM:<f06a7f7f7f7f7f7f7f7f7f7f7f7f7f7f0001020304050607f7f06c7f7f00010101040e07010815091c7f000101010308040e07
2017.12.21 06:55:16 5: FRM:<00610062006c0065004600690072006d006100740061002e0069006e006f00f7f079020643006f006e0066006900670075007200610062006c0065004600690072006d006100740061002e0069006e006f00f7
2017.12.21 06:55:16 5: SW: f06bf7
2017.12.21 06:55:16 5: FRM:>f06bf7
2017.12.21 06:55:16 5: SW: f069f7
2017.12.21 06:55:16 5: FRM:>f069f7
2017.12.21 06:55:16 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_06
2017.12.21 06:55:16 5: FRM:<690072006d006100740061002e0069006e006f00f7e06203e11703e26002e33a02e42602e57b07e67405e73f04f079020643006f006e00660069006700750072
2017.12.21 06:55:16 5: FRM:<f90206f079020643006f006e0066006900670075007200610062006c0065004600
2017.12.21 06:55:15 5: SW: f079f7
2017.12.21 06:55:15 5: FRM:>f079f7
2017.12.21 06:55:15 3: querying Firmata Firmware Version
2017.12.21 06:55:14 5: SW: f079f7
2017.12.21 06:55:14 5: FRM:>f079f7
2017.12.21 06:55:14 3: querying Firmata Firmware Version
2017.12.21 06:55:12 5: SW: ff
2017.12.21 06:55:12 5: FRM:>ff
2017.12.21 06:54:12 3: no response from Firmata, closing DevIO
2017.12.21 06:54:12 5: SW: f079f7
2017.12.21 06:54:12 5: FRM:>f079f7
2017.12.21 06:54:12 3: querying Firmata Firmware Version
2017.12.21 06:54:11 5: SW: f079f7
2017.12.21 06:54:11 5: FRM:>f079f7
2017.12.21 06:54:11 3: querying Firmata Firmware Version
2017.12.21 06:54:10 5: SW: f079f7
2017.12.21 06:54:10 5: FRM:>f079f7
2017.12.21 06:54:10 3: querying Firmata Firmware Version
2017.12.21 06:54:09 5: SW: f079f7
2017.12.21 06:54:09 5: FRM:>f079f7
2017.12.21 06:54:09 3: querying Firmata Firmware Version
2017.12.21 06:54:07 1: fhem_hw:2004 disconnected, waiting to reappear (OWArduino)
2017.12.21 06:54:07 5: SW: ff
2017.12.21 06:54:07 5: FRM:>ff
2017.12.21 06:54:06 1: fhem_hw:2004 disconnected, waiting to reappear (OWArduino)

LG Thomas

ThoTo · 26 Dezember 2017, 16:31:07

So, ich habe jetzt die Zeile 784 mit die(...) in der Funktion onewire_command_series auskommentiert:

FHEM/lib/Device/Firmata/Platform.pm

Code Auswählen

sub onewire_command_series {
  my ( $self, $pin, $args ) = @_;
  die "pin '".$pin."' is not configured for mode 'ONEWIRE'" unless $self->is_configured_mode($pin,PIN_ONEWIRE);
  return $self->{io}->data_write($self->{protocol}->packet_onewire_request( $pin, $args ));
}

Damit stürzt FHEM nicht mehr ab, stattdessen kommt es zu folgenden Logeinträgen und das OWX Device ist auf "disconnected".

Code Auswählen

2017.12.25 20:37:28 1: OWXTHERM_BinValues:  OWX_28_FFCBE6221703: invalid data length, 0 instead of 9 bytes,  0  
2017.12.25 20:37:28 1: OWTHERM: OWX_28_FFCBE6221703 has returned invalid data of length 10
2017.12.25 20:37:23 1: OWXTHERM_BinValues:  OWX_28_FF1DE5221703: invalid data length, 0 instead of 9 bytes,  0  
2017.12.25 20:37:23 1: OWTHERM: OWX_28_FF1DE5221703 has returned invalid data of length 10

Code Auswählen

2017.12.23 10:08:00 1: OWX_FRM::Ready function called for bus OneWireBus. STATE=disconnected
2017.12.23 10:07:20 1: OWX_Complex called while interface OneWireBus disconnected
2017.12.23 10:07:16 1: OWX_Complex called while interface OneWireBus disconnected
2017.12.23 10:07:00 3: OWX_Set OneWireBus reopen => 0
2017.12.23 10:07:00 1: ====> REOPENING DEVICE
2017.12.23 09:42:24 1: OWXTHERM_BinValues:  OWX_28_FFCBE6221703: invalid data length, 0 instead of 9 bytes,  0  
2017.12.23 09:42:24 1: OWTHERM: OWX_28_FFCBE6221703 has returned invalid data of length 10
2017.12.23 09:42:20 1: OWXTHERM_BinValues:  OWX_28_FF1DE5221703: invalid data length, 0 instead of 9 bytes,  0  
2017.12.23 09:42:20 1: PERL WARNING: Use of uninitialized value $data[3] in ord at ./FHEM/21_OWTHERM.pm line 952.
2017.12.23 09:42:20 1: PERL WARNING: Use of uninitialized value $data[2] in ord at ./FHEM/21_OWTHERM.pm line 951.
2017.12.23 09:42:20 1: PERL WARNING: Use of uninitialized value $data[1] in ord at ./FHEM/21_OWTHERM.pm line 939.
2017.12.23 09:42:20 1: PERL WARNING: Use of uninitialized value $data[1] in ord at ./FHEM/21_OWTHERM.pm line 938.
2017.12.23 09:42:20 1: PERL WARNING: Use of uninitialized value $data[0] in ord at ./FHEM/21_OWTHERM.pm line 937.
2017.12.23 09:42:20 1: OWTHERM: OWX_28_FF1DE5221703 has returned invalid data of length 10
2017.12.23 09:40:22 2: CUL_TCM97001 Unknown device Unknown, please define it
2017.12.23 09:38:23 1: fhem_hw:2004 reappeared (OWArduino)
2017.12.23 09:38:23 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_06
2017.12.23 09:38:22 3: querying Firmata Firmware Version
2017.12.23 09:38:21 3: querying Firmata Firmware Version
2017.12.23 09:38:18 1: fhem_hw:2004 disconnected, waiting to reappear (OWArduino)

Wenn ich dann das define des OWX-Devices auf zB Pin 18 und wieder zurück auf Pin 19 ändere, ein reopen mache, funktioniert wieder alles.

Code Auswählen

2017.12.23 20:37:37 1: OWX: 1-Wire bus OneWireBus: interface Firmata detected in OWArduino
2017.12.23 20:37:04 1: OWX: 1-Wire bus OneWireBus: interface Firmata detected in OWArduino
2017.12.23 20:36:37 1: Error: >OWArduino:19< has no TYPE, but following keys: ><
2017.12.23 20:36:04 1: Error: >OWArduino:18< has no TYPE, but following keys: ><

Hier noch ein list des OWX-Devices im funktionierenden Zustand:

Code Auswählen

Internals:
   ALARMED    2
   ASYNCHRONOUS 0
   CFGFN      
   DEF        OWArduino:19
   DeviceName OWArduino:19
   FRM_OWX_CORRELATIONID 444
   FRM_OWX_CURRDEV 28.FFCBE6221703.E1
   HWDEVICE   OWArduino
   INITDONE   1
   INTERFACE  firmata
   IODev      OWArduino
   NAME       OneWireBus
   NEXT_OPEN  1514235363.50745
   NR         226
   PARTIAL    
   PIN        19
   PRESENT    1
   ROM_ID     FF
   STATE      Initialized
   TYPE       OWX
   interval   300
   timeout    2
   version    7.05
   DEVHASH:
     OWX_28_FF1DE5221703 28.FF1DE5221703.AB
     OWX_28_FFCBE6221703 28.FFCBE6221703.E1
     OneWireBus Busmaster
   DEVS:
     28.FF1DE5221703.AB
     28.FFCBE6221703.E1
   FRM_OWX_REPLIES:
     28.FF1DE5221703.AB �KF���
     28.FFCBE6221703.E1 �KF����
   FRM_OWX_REQUESTS:
	 ...
   READINGS:
     2017-12-21 20:26:54   queue           0
     2017-12-25 20:40:46   state           disconnected
Attributes:
   asynchronous 0
   verbose    0

Ich verschiebe das Thema nun nach 1Wire, vielleicht kommen dann noch Ideen

LG Thomas

JensS · 26 Dezember 2017, 18:59:51

Hallo Thomas,

probier mal die 10_FRM.pm: https://forum.fhem.de/index.php/topic,80409.msg724359.html#msg724359

Gruß Jens

ThoTo · 28 Dezember 2017, 16:42:57

Zitat von: dirigent am 26 Dezember 2017, 18:59:51
Hallo Thomas,

probier mal die 10_FRM.pm: https://forum.fhem.de/index.php/topic,80409.msg724359.html#msg724359

Gruß Jens

Danke, Jens!
Habe ich eingebaut, werde nun weiter beobachten und berichten.

LG Thomas

ThoTo · 29 Dezember 2017, 10:28:58

Zitat von: dirigent am 26 Dezember 2017, 18:59:51
probier mal die 10_FRM.pm: https://forum.fhem.de/index.php/topic,80409.msg724359.html#msg724359

Leider ohne Ergebnis, FHEM ist heute Nacht wieder mit "pin '19' is not configured for mode 'ONEWIRE' at FHEM/lib/Device/Firmata/Platform.pm line 784." stehengeblieben.
Das Auskommentieren der die()-Funktionen habe ich zuvor wieder rückgängig gemacht.

LG THomas

JensS · 29 Dezember 2017, 10:41:11

Hallo Thomas,

poste mal die Ausgabe von "list OWArduino".

Gruß Jens

ThoTo · 29 Dezember 2017, 11:24:50

list OWArduino

Code Auswählen

Internals:
   CFGFN      
   DEF        fhem_hw:2004
   DeviceName fhem_hw:2004
   FD         71
   NAME       OWArduino
   NOTIFYDEV  global
   NR         219
   NTFY_ORDER 50-OWArduino
   PARTIAL    
   STATE      Initialized
   TYPE       FRM
   analog_pins 14,15,16,17,18,19,20,21
   analog_resolutions 14:10,15:10,16:10,17:10,18:10,19:10,20:10,21:10
   encoder_pins 2,3
   encoder_resolutions 2:28,3:28
   firmware   ConfigurableFirmata.ino
   firmware_version V_2_06
   i2c_pins   18,19
   input_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
   onewire_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
   output_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
   pwm_pins   3,5,6,9,10,11
   pwm_resolutions 3:8,5:8,6:8,9:8,10:8,11:8
   servo_pins 2,3,4,5,6,7,8,9,10,11,12,13
   servo_resolutions 2:14,3:14,4:14,5:14,6:14,7:14,8:14,9:14,10:14,11:14,12:14,13:14
   stepper_pins 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
   stepper_resolutions 2:21,3:21,4:21,5:21,6:21,7:21,8:21,9:21,10:21,11:21,12:21,13:21,14:21,15:21,16:21,17:21,18:21,19:21
   READINGS:
     2017-12-29 08:10:18   state           opened
Attributes:
   group      USB Dongle
   room       System
   verbose    0

LG Thomas

JensS · 29 Dezember 2017, 18:43:07

$:-\$ Vielleicht hat noch jemand anderes eine Idee dazu...
Hast du schon mal probiert, den Arduino direkt über /dev/serial/by-id/... anzusprechen?

Gruß Jens

jensb · 01 Januar 2018, 23:19:26

@ThoTo

Habe heute eine Anpassung von FRM für OWX vorbereitet. Beim Testen ist mir FHEM auch mehrfach abgestürzt. Das liegt u.a. am Modul OWX_FRM, das bei bestimmten Fehlern keine erweiterte Fehlerbehandlung macht. Anbei eine inoffizielle Version zum Testen - Maintainer von 11_OWX_FRM.pm ist @pahenning.

Die neue Version von FRM zum Testen findet man hier (das FRM-Modul allein reicht nicht für Test, bitte den ganzen Thread durchlesen).

Selbst wenn die beiden Updates zusammen die Ursache nicht beheben, dürft dein FHEM danach nicht mehr aus diesem Grund abstürzen.

Grüße,
Jens

UPDATE 07.01.2018: 11_OWX_FRM.pm aktualisiert

ThoTo · 01 Januar 2018, 23:47:41

Zitat von: jensb am 01 Januar 2018, 23:19:26

Die neue Version von FRM zum Testen findet man hier (das FRM-Modul allein reicht nicht für Test, bitte den ganzen Thread durchlesen).

Dankeschön, Jens! Habe den Thread verfolgt, komme aber erst morgen dazu die geänderten Files einzubauen.
Feedback folgt.

LG Thomas

rino · 08 Januar 2018, 20:47:30

Moin habe die FRM Version getestet.
Bei mir stürzt Fhem jedenfalls nicht mehr ab.
Mein Temperatur Sensoren liefen zu Anfang.
Dann kam es aber zu einem Disconnect meines Arduino Nano an welchem die ds18b20 hängen.
Der Nano läuft mir V2.10 der Firmata.

Hier ein Log Ausschnitt:

Code Auswählen


2018.01.08 02:12:55 1: OWX_FRM::Complex receiving inside loop no. 0 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0xbe 0xfe 0x01 0x55 0x00 0x7f 0xff 0xff 0xff 0x32 
2018.01.08 02:12:55 1: OWX_FRM::Complex receiving outside loop 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x44 
2018.01.08 02:12:56 1: OWX_FRM::Complex receiving inside loop no. 0 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0xbe 0x16 0x02 0x55 0x00 0x7f 0xff 0xff 0xff 0x2c 
2018.01.08 02:16:51 1: /dev/ttyUSB0 disconnected, waiting to reappear (ArduinoHWR)
2018.01.08 02:16:53 3: Setting ArduinoHWR serial parameters to 57600,8,N,1
2018.01.08 02:16:53 1: /dev/ttyUSB0 reappeared (ArduinoHWR)
2018.01.08 02:16:56 3: ArduinoHWR querying Firmata versions
2018.01.08 02:16:57 3: ArduinoHWR Firmata Firmware Version: hwr.ino V_2_10 (using Protocol Version: V_2_06)

Danach keine aktuellen Temperaturen Daten mehr.

Gruß

Reiner Emkes

JensS · 08 Januar 2018, 22:01:27

Hallo Reiner,

sichere mal die fhem.save zur späteren Analyse und lösche dann sämtliche Readings vom ArduinoHWR, dem OWX und dem DS18b20 mit deletereading ArduinoHWR .* etc.. Anschließend mit save alles sichern und shutdown restart. Ich hatte das gleiche Problem und konnte es so lösen.

Gruß Jens

ThoTo · 08 Januar 2018, 22:42:22

Ich glaube ja mittlerweile dass der Arduino neu startet.
Müsste mir mal meine Configurable Firmata Config ansehen und evt. optimieren.

LG Thomas

rino · 08 Januar 2018, 22:53:57

Hallo Jens,
Vielen Dank, hat geklappt.
Jetzt kommen wieder Temperatur Werte.
Ich melde mich morgen, ob es noch läuft.
Gruß
Reiner

Joerg · 08 Januar 2018, 23:28:15

Hallo Thomas,

hatte ein aehnliches Problem. Firmata CPU war ueber 20m seriell mit einem FTDI und RPI verbunden. Da ist die Baudrate zu hoch. Mit 9600 funktioniert es jetzt.

Gruss

Joerg

jensb · 08 Januar 2018, 23:40:30

Das Log von @rino sieht für mich so aus, als ob der Arduino sich resettet (z.B. zu wenig Speicher?). Nach dem Reset initialisiert das FRM-Device die Verbindung neu. OWX bzw. OWX_FRM implementieren aber keine InitFn, bekommen den Reconnect scheinbar nicht mit und bleiben hängen. OWX ist aktuell möglicherweise nicht reconnectfähig.

Grüße,
Jens

JensS · 09 Januar 2018, 07:12:14

Hallo Thomas,

wenn du am Arduino i2c nutzt, dann wäre ein "attr fhem_hw i2c-config 30000" einen Versuch wert.

Gruß Jens

ThoTo · 09 Januar 2018, 07:15:56

Zitat von: jensb am 08 Januar 2018, 23:40:30
Das Log von @rino sieht für mich so aus, als ob der Arduino sich resettet (z.B. zu wenig Speicher?). Nach dem Reset initialisiert das FRM-Device die Verbindung neu. OWX bzw. OWX_FRM implementieren aber keine InitFn, bekommen den Reconnect scheinbar nicht mit und bleiben hängen. OWX ist aktuell möglicherweise nicht reconnectfähig.

Grüße,
Jens

Ja, genau dieses Verhalten hatte ich beobachtet.
Nur mit dem Nebeneffekt, dass FHEM ohne deinen Patch abgestürzt ist.

@pah hat noch in keinem der offenen Threads eine Rückmeldung gegeben, oder?

LG Thomas

rino · 09 Januar 2018, 14:56:10

Moin,

wollte mich ja melden. OWX hat seinen Dienst wieder eingestellt

Code Auswählen

2018.01.09 06:47:48 1: OWX_FRM::Complex receiving outside loop 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x44 
2018.01.09 06:47:49 1: OWX_FRM::Complex receiving inside loop no. 0 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0xbe 0x9a 0x03 0x55 0x00 0x7f 0xff 0xff 0xff 0xbc 
2018.01.09 06:48:17 1: /dev/ttyUSB0 disconnected, waiting to reappear (ArduinoHWR)
2018.01.09 06:48:18 3: Setting ArduinoHWR serial parameters to 57600,8,N,1
2018.01.09 06:48:18 1: /dev/ttyUSB0 reappeared (ArduinoHWR)
2018.01.09 06:48:21 3: ArduinoHWR querying Firmata versions
2018.01.09 06:48:23 3: ArduinoHWR Firmata Firmware Version: hwr.ino V_2_10 (using Protocol Version: V_2_06)

Daher gehe ich wie Jens davon aus, das ..

Zitat von: jensb am 08 Januar 2018, 23:40:30
OWX ist aktuell möglicherweise nicht reconnectfähig.

Grüße,
Jens

ist, da mein S0-Stromzähler, welcher am gleichen Arduino hängt, fleissig weiter zählt.

Code Auswählen

Internals:
   DEF        3
   IODev      ArduinoHWR
   NAME       strom_counter
   NR         302
   PIN        3
   STATE      Watt: 268.09  kWh: 772.44
   TYPE       FRM_IN
   READINGS:
     2018-01-09 14:54:39   count           6068
     2018-01-09 14:54:39   power           268.088727911901
     2018-01-09 14:54:39   powersum        772.439499999697
     2018-01-09 14:54:39   powersum_HausZ  76503.2449998623
     2018-01-09 14:54:39   reading         off
     2018-01-09 06:48:23   state           Initialized
     2018-01-09 14:54:39   time            1515506079.59032

Gruß

Reiner

Update:

Ein einfaches restart reicht bei mit aus, dann werden wieder Temperaturen geloggt.

Ich glaub, das fehlt:

Code Auswählen

2018.01.09 14:59:50 1: OWX_Init called for bus heiztemp with interface state Initialized, now going for detect

JensS · 09 Januar 2018, 21:57:59

Hallo Thomas, hast du die fhem.save gesichert? Mich würden die gelöschten Readings interessieren. Gruß Jens

jensb · 09 Januar 2018, 22:24:16

Hallo Reiner,

versuch herauszufinden, warum sich dein Arduino resettet. Selbst wenn der OWX-Reconnect klappen würde, ist das so keine Lösung und normal ist das auch nicht. Ein Arduino mit Firmata sollte ein Daueräufer sein.

Ein paar Vorschläge gab es ja schon von @Joerg und mir: Leitungslänge (Störeinkopplungen), Netzteil (Spannungsstabilität), Speicher. Serielles Debuggen ist leider nicht so einfach, wenn du USB verwendest. Dazu müsstest du einen passenden Arduino mit freien seriellen Pins und genug Speicher für SerialFirmata haben.

Was bei OWX/OWX_FRM klemmt, kann ich nicht ohne weiteres herausfinden, da ich keinen passenden Testaufbau habe. Habe mir OWX und OWX_FRM erneut angesehen habe. Es gibt zwar keine InitFn aber eine ReadyFn. Mit der ReadyFn kann man z.T. auch Connects und Disconnects von IO-Devices erkennen. Wenn ich das richtig sehe, ist FRM das IODevice von OWX. Daher würde ich zuerst in OWX_Ready in jede Zeile ein Logging einbauen, um herauszufinden, ob Ready überhaupt bei einem Firmata-Reset reagiert und wenn ja, wo es momentan langläuft. Ist möglicherweise eine Sackgasse, aber einen Versuch wert.

Grüße,
Jens

ThoTo · 10 Januar 2018, 12:37:27

Hallo Jens!

Zitat von: dirigent am 09 Januar 2018, 07:12:14
wenn du am Arduino i2c nutzt, dann wäre ein "attr fhem_hw i2c-config 30000" einen Versuch wert.

Leider nein, nutze 1Wire.

Zitat von: dirigent am 09 Januar 2018, 21:57:59
Hallo Thomas, hast du die fhem.save gesichert? Mich würden die gelöschten Readings interessieren. Gruß Jens

War das für mich?

Werde sie trotzdem sichern, wenn das nächste Mal etwas auftritt.

Was ich auf jeden Fall versuche ist die Baudrate runterzudrehen und werden mich auch nochmal mit dem Arduino beschäftigen.....

LG Thomas

rino · 10 Januar 2018, 15:27:15

Zitat von: jensb am 09 Januar 2018, 22:24:16
versuch herauszufinden, warum sich dein Arduino resettet. Selbst wenn der OWX-Reconnect klappen würde, ist das so keine Lösung und normal ist das auch nicht. Ein Arduino mit Firmata sollte ein Daueräufer sein.

Ich habe meine alten Logs angeschaut. Vor dem Update (ich meine im Oktober) hat sich der Arduino auch zwischendurch resettet.
Das ist mir nicht weiter aufgefallen, da es da ja lief.

Ich werde mir also bei Gelegenheit das ganze mal anschauen.

Somit erstmal vielen Dank für die Tipps

Gruß

Reiner

JensS · 10 Januar 2018, 16:37:34

Ok, Brief kam auf Grund falscher Adresse zurück. Diesmal richtig:

@Reiner, hast du die fhem.save gesichert? Mich würden die gelöschten Readings interessieren.

@Thomas, wenn du i2c und andere Features nicht nutzt, dann deaktiviere sie besser im Sketch.

Zitati2c_pins 18,19

Gruß Jens

rino · 10 Januar 2018, 19:42:24

Zitat von: dirigent am 10 Januar 2018, 16:37:34
@Reiner, hast du die fhem.save gesichert? Mich würden die gelöschten Readings interessieren.

Gruß Jens

Dieses hier?

Code Auswählen


#Mon Jan  8 00:40:14 2018

setstate ArduinoHWR 2018-01-08 00:37:45 state Initialized

setstate FileLog_Speicher_ruecklauf active
setstate FileLog_Speicher_ruecklauf 2018-01-08 00:35:18 linesInTheFile 482
setstate FileLog_Speicher_temp active
setstate FileLog_Speicher_temp 2018-01-08 00:35:19 linesInTheFile 522
setstate FileLog_Speicher_vorlauf active
setstate FileLog_Speicher_vorlauf 2018-01-08 00:35:20 linesInTheFile 220

setstate FileLog_ruecklauf active
setstate FileLog_ruecklauf 2018-01-08 00:35:21 linesInTheFile 498
setstate FileLog_vorlauf active
setstate FileLog_vorlauf 2018-01-08 00:35:22 linesInTheFile 498

setstate SVG_FileLog_Speicher_temp_1 initialized

setstate SVG_FileLog_vorlauf_1 initialized

setstate Speicher_ruecklauf 2018-01-08 00:37:40 state defined
setstate Speicher_ruecklauf 2018-01-08 00:35:18 temperature 37.625
setstate Speicher_temp defined
setstate Speicher_temp 2018-01-08 00:37:40 state defined
setstate Speicher_temp 2018-01-08 00:35:19 temperature 56.625
setstate Speicher_vorlauf defined
setstate Speicher_vorlauf 2018-01-08 00:37:40 state defined
setstate Speicher_vorlauf 2018-01-08 00:35:20 temperature 27.25

setstate heiztemp 2018-01-08 00:37:37 queue 0
setstate heiztemp 2018-01-07 22:24:08 state disconnected

setstate log_strom_counter active
setstate log_strom_counter 2018-01-08 00:40:10 linesInTheFile 155770

setstate ruecklauf defined
setstate ruecklauf 2018-01-08 00:37:40 state defined
setstate ruecklauf 2018-01-08 00:35:21 temperature 34.5625
setstate strom_counter Watt: 147.50  kWh: 765.17
setstate strom_counter 2018-01-08 00:40:10 count 12
setstate strom_counter 2018-01-08 00:40:10 power 147.496068805098
setstate strom_counter 2018-01-08 00:40:10 powersum 765.165499999869
setstate strom_counter 2018-01-08 00:40:10 powersum_HausZ 76495.9709999402
setstate strom_counter 2018-01-08 00:40:10 reading off
setstate strom_counter 2018-01-08 00:37:45 state Initialized
setstate strom_counter 2018-01-08 00:40:10 time 1515368410.1253
setstate vorlauf defined
setstate vorlauf 2018-01-08 00:37:40 state defined
setstate vorlauf 2018-01-08 00:35:22 temperature 37.8125

JensS · 10 Januar 2018, 20:58:25

Danke, leider nichts Auffälliges dabei. Gruß Jens

jensb · 10 Januar 2018, 22:00:01

@rino hatte geschrieben

ZitatEin einfaches restart reicht bei mit aus, dann werden wieder Temperaturen geloggt.

Vielleicht ist es vor allem der Neustart, der hilft. Beim Neustart werde alle Internals gelöscht, denn die stehen nicht in der fhem.save. Module arbeiten gern mit den Internals, gerade bei Kommunikationsabläufen. Um herauszufinden, welches Internal es sein könnte, müsste man einen Screenshot vom OWX-Device machen, bevor man neu startet und einen weiteren nach dem Neustart, aber mit vorher entferntem Arduino, damit keine Verbindung aufgebaut wird.

Die ReadyFn des OWX_FRM-Moduls ist übrigens ein Dummy, d.h. sie kann nicht feststellen, ob sich USB oder LAN verbunden oder getrennt haben. Was passiert eigentlich, wenn man z.B. am OWX-Device "set closeopen" oder "set reopen" aufruft, wenn die Kommunikation klemmt?

Grüße,
Jens

rino · 10 Januar 2018, 22:30:08

OK, melde mich wenn es wieder klemmt.
Zur Zeit läuft es ja...

Gruß

Reiner

abc2006 · 11 Januar 2018, 00:41:44

mit dem Speicheroptimieren häng ich mich hier mal rein... für Onewire braucht man nur FirmataExt und Onewire?
Habe verschiedenes gelesen, dass da diverse Abhängigkeiten bestehen, aber bisher keine gute Lösung gefunden..

Weiss jemand sicher, welche Teile man für (ausschließlich) onewireFirmata braucht?
Vielleicht sinds bei mir ja auch Speicherprobleme ...

Grüße,
Stephan

ThoTo · 11 Januar 2018, 20:29:01

Zitat von: dirigent am 10 Januar 2018, 16:37:34
@Thomas, wenn du i2c und andere Features nicht nutzt, dann deaktiviere sie besser im Sketch.
Gruß Jens

Danke für den Hinweis, habe ich gemacht.
Am Arduino läuft jetzt die aktuelle Firmata-Version, aktiv sind nur mehr 1Wire sowie In/Out....

LG Thomas

jensb · 14 Januar 2018, 18:39:41

Reconnect-Update

Habe einen Testaufbau zusammengestellt aus Orange Pi Zero, Teensy LC und DS18B20. Im Testaufbau klemmt noch die eigentliche Messdatenabfrage vom DS18B20 - aktuell klappt nur die OneWire Device-Identifizierung, trotzdem konnte ich viele Abläufe überprüfen.

OWX_FRM kann in der bisherigen Version kein Reconnect, da OWX_FRM::Init und das OWX Discover nur einmal timergesteuert beim FHEM Neustart ausgeführt werden. Ist das Firmata-Device zu diesem Zeitpunkt nicht verbunden, wars das. Habe diverse Ansätze ausprobiert. Nun wird OWX_FRM::Init jedes mal nach dem Initialisieren der Verbindung zum Firmata-Device aufgerufen. Man kann nun z.B. das USB-Kabel vom Firmata-Device abziehen und wieder stecken - das OWX-Device wird wieder gefunden.

Bitte mal ausprobieren.

Grüße,
Jens

UPDATE: Habe den Teensy LC gegen einen Mini getauscht, jetzt bekomme ich auch Temperaturmesswerte.

JensS · 14 Januar 2018, 19:05:59

läuft...

Mich würde interessieren, wie es modulübergreifend in der Kommunikation auf Layer 8 funktioniert. Muss ich 11_OWX_FRM.pm jetzt per "attr global exlude_from_update 11_OWX_FRM.pm" von offiziellen Updates ausschließen?

Gruß Jens

ThoTo · 14 Januar 2018, 19:21:29

Zitat von: dirigent am 14 Januar 2018, 19:05:59
Mich würde interessieren, wie es modulübergreifend in der Kommunikation auf Layer 8 funktioniert. Muss ich 11_OWX_FRM.pm jetzt per "attr global exlude_from_update 11_OWX_FRM.pm" von offiziellen Updates ausschließen?

Ja, zumindest so lange bis die geänderte Version von pah eingecheckt wird.

LG Thomas

jensb · 14 Januar 2018, 19:56:43

ZitatMuss ich 11_OWX_FRM.pm jetzt per "attr global exlude_from_update 11_OWX_FRM.pm" von offiziellen Updates ausschließen?

Das wäre auch meine Empfehlung, wenn diese Version besser läuft als die offizielle Version. Der Update-Patch für 11_OWX_FRM.pm muss noch aktualisiert werden, damit pah das nicht zweimal angehen muss. Das werde ich erst Ende der neuen Woche machen, um noch ein paar Rückmeldungen einzusammeln.

Grüße,
Jens

Prof. Dr. Peter Henning · 15 Januar 2018, 10:02:42

Ich werde das dann sicher zeitnah einchecken, denn das brennt mir auf der Agenda. Allerdings bitte ich noch einmal um Verständnis, dass ich nicht jede Konfiguration nachbauen konnte, dafür habe ich zu viele Baustellen. Also danke allen Mitwirkenden !

LG

pah

ThoTo · 15 Januar 2018, 18:25:19

Zitat von: jensb am 14 Januar 2018, 18:39:41
OWX_FRM kann in der bisherigen Version kein Reconnect, da OWX_FRM::Init und das OWX Discover nur einmal timergesteuert beim FHEM Neustart ausgeführt werden. Ist das Firmata-Device zu diesem Zeitpunkt nicht verbunden, wars das. Habe diverse Ansätze ausprobiert. Nun wird OWX_FRM::Init jedes mal nach dem Initialisieren der Verbindung zum Firmata-Device aufgerufen. Man kann nun z.B. das USB-Kabel vom Firmata-Device abziehen und wieder stecken - das OWX-Device wird wieder gefunden.

File ist aktualisiert, ich berichte.
Generell sieht es jetzt schon ganz gut aus, keine Auffälligkeiten.

LG Thomas

rino · 15 Januar 2018, 22:18:23

Moin,

vielen Dank für das schnelle Update.
Gestern eingespielt und bis jetzt keine Aussetzer mehr.

Noch zur Info: Beim letzten Hänger der Alten OWX Version reichte doch kein einfacher Restart. Erst nach nochmaligen Reset funktionierten die Temperaturreadings wieder.

Gruß

Reiner

jensb · 15 Januar 2018, 22:41:50

@pah
Danke für das Angebot bzgl. des Eincheckens. Bitte warte damit noch bis ich den Patch aktualisiert habe. In der jetzigen Version ist ein Debug-Log noch nicht wieder auskommentiert.

Grüße,
Jens

rino · 16 Januar 2018, 15:36:15

Noch zur Info,

das ist ein Output, wenn der Arduino sich bei mir resettet:

Code Auswählen

2018.01.16 10:32:02 1: /dev/ttyUSB0 disconnected, waiting to reappear (ArduinoHWR)
2018.01.16 10:32:04 3: Setting ArduinoHWR serial parameters to 57600,8,N,1
2018.01.16 10:32:04 1: /dev/ttyUSB0 reappeared (ArduinoHWR)
2018.01.16 10:32:07 3: ArduinoHWR querying Firmata versions
2018.01.16 10:32:09 3: ArduinoHWR Firmata Firmware Version: hwr.ino V_2_10 (using Protocol Version: V_2_06)
2018.01.16 10:32:19 1: =============> result from search is 0, iodev is HASH(0x3498d20)

Wie gesagt, läuft aber jetzt alles wieder. Readings werden weitergeschrieben.

Gruß

Reiner

jensb · 16 Januar 2018, 20:06:48

Hallo Rainer,

du meinst die Zeile mit den "===>"? Die Ausgabe ist harmlos. Ich hatte im Modul OWX_FRM deaktivierte Logausgaben wieder aktiviert, um besser zu sehen, was unter der Haube passiert. Hatte das schon gestern Abend wieder ausgebaut, nachdem die ersten positiven Rückmeldungen kamen. Die Reconnect-Update-Version habe ich gerade aktualisiert, mit der sollte dieses Logging wieder weg sein.

Grüße,
Jens

rino · 17 Januar 2018, 16:25:46

Hallo Jens,

das hatte ich mir schon gedacht. Gewundert hat mich nur die 0 in "result from search is".
Jedenfalls Danke für die Mühe.

Gruß

Reiner

ThoTo · 20 Januar 2018, 16:33:54

So, nach 5 Tagen kein Crash und keine Probleme mehr.
Die Kombination OWX und FRM funktioniert wieder einwandfrei.

Vielen Dank für deine Arbeit @jensb

LG Thomas

jensb · 20 Januar 2018, 19:24:01

Hallo,

Danke für die Rückmeldungen.

Als ich das Firmata 2.7+ Update vorbereitet habe, sind mir die bereits bestehenden Probleme mit OneWire nicht aufgefallen, da ich OneWire selbst nicht verwende. Der Rest war ein interessanter "Hack" des FHEM Moduls 11_OWX_FRM.pm, mit dem ich vorher nichts zu tun hatte. Freut mich, dass es hilft.

Grüße,
Jens