Autor Thema: [gelöst] komisches LOG Verhalten bei EINEM FHT Sensor  (Gelesen 867 mal)

Offline Thoffi1978

  • Full Member
  • ***
  • Beiträge: 371
Hallo,
ich habe 3 FHT´s.
Nach Einrichtung funktionieren alle tadellos.
Wenn ich FHEM neu starte, gibt es einen FHT Sensor, der aus dem Kinderzimmer, der in FHEM nicht mehr aktualisiert wird.
Die anderen Beiden laufen.

Klicke ich auf  DeviceOverview und dann auf DEF und gleich wieder auf modify, läuft der Sensor auch wieder korrekt. Ich habe keine Änderung in der Definition dabei vorgenommen.

Warum startet dieser eine Sensor nicht richtig?

List vom Sensor:
Internals:
   .lastTimeactuator 1529431441.9942
   CODE       174b
   CUL_MSGCNT 666
   CUL_RAWMSG 810c04xx0909a001174b0000aaff
   CUL_RSSI   -63.5
   CUL_TIME   2018-06-19 20:04:01
   DEF        174b
   IODev      CUL
   LASTInputDev CUL
   MSGCNT     666
   NAME       KiZi_Heizung
   NR         43
   STATE      ???
   TYPE       FHT
   .attraggr:
   .attrminint:
     .*:300
   READINGS:
     2018-06-19 20:04:01   actuator        100%
     2018-03-15 11:29:48   actuator1       pair
Attributes:
   IODev      CUL
   event-min-interval .*:300
   retrycount 3
   room       FHT

Vielen Dank
Hoffi
« Letzte Änderung: 01 Juli 2018, 10:47:14 von Thoffi1978 »

Offline amenomade

  • Hero Member
  • *****
  • Beiträge: 2624
Antw:komisches LOG Verhalten bei EINEM FHT Sensor
« Antwort #1 am: 19 Juni 2018, 20:14:51 »
Haben die funktionierenden auch event-min-interval gesetzt?
FHEM 5.8 Pi 3, EchoDot, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, und HM Komponenten

F:"Schatz? Mach aus bitte"
M: "Alexa? Licht aus"-"Ich bin mir leider nicht sicher"  M:"Alexa? aus Licht"-"Das weiss ich leider nicht" M:"Alexa? Schalte...
F: "Drück mal auf den blöden Knopf!

Offline Thoffi1978

  • Full Member
  • ***
  • Beiträge: 371
Antw:komisches LOG Verhalten bei EINEM FHT Sensor
« Antwort #2 am: 19 Juni 2018, 20:25:28 »
JA,
alle haben die gleichen Attributes.

Hier ein List vom "Schlafzimmer" der nach Neustart funktioniert:

List SchlafZi:
Internals:
   .lastTimeactuator 1529432424.31878
   CHANGED   
   CODE       0403
   CUL_MSGCNT 2146
   CUL_RAWMSG 810c04xx0909a00104030000aaff
   CUL_RSSI   -41
   CUL_TIME   2018-06-19 20:22:20
   DEF        0403
   IODev      CUL
   LASTInputDev CUL
   MSGCNT     2146
   NAME       Schlaf_Heizung
   NR         51
   STATE      ???
   TYPE       FHT
   .attraggr:
   .attrminint:
     .*:300
   READINGS:
     2018-06-19 20:22:20   actuator        100%
     2018-03-15 11:17:05   actuator1       pair
Attributes:
   IODev      CUL
   event-min-interval .*:300
   retrycount 3
   room       FHT

Offline amenomade

  • Hero Member
  • *****
  • Beiträge: 2624
Antw:komisches LOG Verhalten bei EINEM FHT Sensor
« Antwort #3 am: 19 Juni 2018, 22:50:57 »
Ich würde den problematischen auf verbose 5 setzen, (natürlich speichern), und dann beim neustart von Fhem gucken, ob etwas in der Log kommt.
FHEM 5.8 Pi 3, EchoDot, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, und HM Komponenten

F:"Schatz? Mach aus bitte"
M: "Alexa? Licht aus"-"Ich bin mir leider nicht sicher"  M:"Alexa? aus Licht"-"Das weiss ich leider nicht" M:"Alexa? Schalte...
F: "Drück mal auf den blöden Knopf!

Offline Thoffi1978

  • Full Member
  • ***
  • Beiträge: 371
Antw:komisches LOG Verhalten bei EINEM FHT Sensor
« Antwort #4 am: 20 Juni 2018, 09:55:05 »
Hallo,
 ich habe verbose 5 gesetzt. Ich finde im Log nichts, füge es unten mit an.
Die List vom Sensor hat sich geändert:

Internals:
   CODE       174b
   DEF        174b
   IODev      CUL
   NAME       KiZi_Heizung
   NR         43
   STATE      ???
   TYPE       FHT
   .attrminint:
     .*:300
   READINGS:
     2018-06-20 09:41:28   actuator        100%
     2018-03-15 11:29:48   actuator1       pair
Attributes:
   IODev      CUL
   event-min-interval .*:300
   retrycount 3
   room       FHT
   verbose    5
zum Vergleich, der aus dem SchlafZi:
Internals:
   .lastTimeactuator 1529480655.6766
   CHANGED   
   CODE       0403
   CUL_MSGCNT 3
   CUL_RAWMSG 810c04xx0909a00104030000aaff
   CUL_RSSI   -40
   CUL_TIME   2018-06-20 09:48:08
   DEF        0403
   IODev      CUL
   LASTInputDev CUL
   MSGCNT     3
   NAME       Schlaf_Heizung
   NR         51
   STATE      ???
   TYPE       FHT
   .attraggr:
   .attrminint:
     .*:300
   READINGS:
     2018-06-20 09:48:08   actuator        100%
     2018-03-15 11:17:05   actuator1       pair
Attributes:
   IODev      CUL
   event-min-interval .*:300
   retrycount 3
   room       FHT

Log nach Neustart:
2018.06.20 09:41:56 1: RMDIR: ./restoreDir/save/2018-06-17
2018.06.20 09:42:30 0: Server shutdown
2018.06.20 09:42:30 3: WhatsApp: sending /disconnect
2018.06.20 09:42:30 3: WhatsApp: Disconnected
2018.06.20 09:42:34 1: Including fhem.cfg
2018.06.20 09:42:34 3: global: unknown attribute uniqueID. Type 'attr global ?' for a detailed list.
2018.06.20 09:42:34 3: telnetPort: port 7072 opened
2018.06.20 09:42:34 3: WEB: port 8083 opened
2018.06.20 09:42:34 3: WEBphone: port 8084 opened
2018.06.20 09:42:34 3: WEBtablet: port 8085 opened
2018.06.20 09:42:34 3: WEBkamera: port 8086 opened
2018.06.20 09:42:36 2: eventTypes: loaded 4488 events from ./log/eventTypes.txt
2018.06.20 09:42:36 3: Opening nanoCUL device /dev/ttyUSB0
2018.06.20 09:42:36 3: Setting nanoCUL serial parameters to 38400,8,N,1
2018.06.20 09:42:39 3: nanoCUL: Possible commands: ABCeFfGiKLlMNRTtUVWXx
2018.06.20 09:42:39 3: nanoCUL device opened
2018.06.20 09:42:39 3: Opening CUL device /dev/ttyACM0
2018.06.20 09:42:39 3: Setting CUL serial parameters to 9600,8,N,1
2018.06.20 09:42:39 3: CUL: Possible commands: ABbCeFGhiKkLlMmNRTtUuVWXxYZ
2018.06.20 09:42:39 3: CUL device opened
2018.06.20 09:42:39 1: HMLAN_Parse: hmusb new condition disconnected
2018.06.20 09:42:39 3: Opening hmusb device 127.0.0.1:1234
2018.06.20 09:42:39 1: HMLAN_Parse: hmusb new condition init
2018.06.20 09:42:39 3: hmusb device opened
2018.06.20 09:42:41 3: Opening Callmonitor device 192.168.2.1:1012
2018.06.20 09:42:44 3: Helligkeit: Defined with URL http://Fhem:fhem1234@192.168.2.12/control/rcontrol?action=gettext&message=$(SEN.LXR) and interval 120
2018.06.20 09:42:44 2: WhatsApp: starting yoswup-cli: /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup
/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py:1268: UserWarning: /opt/fhem/.python-eggs is writable by group/others and vulnerable to attack when used with get_resource_filename. Consider a more secure location (set with .set_extraction_path or the PYTHON_EGG_CACHE environment variable).
  warnings.warn(msg, UserWarning)
2018.06.20 09:42:47 3: DBPlan_Define (OD_Rst) - defined with interval 120 (sec)
2018.06.20 09:42:47 3: DBPlan_Define (OD_Rst) - defined with base type plan
2018.06.20 09:42:47 3: DBPlan (OD_Rst) - loading station file /opt/fhem/FHEM/deutschland_bhf.csv
2018.06.20 09:42:47 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_DBPlan.pm line 1727.
2018.06.20 09:42:47 2: DBPlan (OD_Rst) - read 7090 stations from station file
2018.06.20 09:42:47 3: DBPlan_Attr (OD_Rst) - destination set to xx
2018.06.20 09:42:47 3: DBPlan_Attr (OD_Rst) - set dbplan_journey_prod : Alle
2018.06.20 09:42:47 3: DBPlan_Attr (OD_Rst) - station set to xx
2018.06.20 09:42:47 3: DBPlan_Attr (OD_Rst) - set room : ÖPNV
2018.06.20 09:42:47 3: DBPlan_Define (Rst_OD) - defined with interval 120 (sec)
2018.06.20 09:42:47 3: DBPlan_Define (Rst_OD) - defined with base type plan
2018.06.20 09:42:47 3: DBPlan (Rst_OD) - loading station file /opt/fhem/FHEM/deutschland_bhf.csv
2018.06.20 09:42:48 2: DBPlan (Rst_OD) - read 7090 stations from station file
2018.06.20 09:42:48 3: DBPlan_Attr (Rst_OD) - destination set to xx
2018.06.20 09:42:48 3: DBPlan_Attr (Rst_OD) - set dbplan_journey_prod : Alle
2018.06.20 09:42:48 3: DBPlan_Attr (Rst_OD) - station set to xx
2018.06.20 09:42:48 3: DBPlan_Attr (Rst_OD) - set room : ÖPNV
2018.06.20 09:42:48 3: DBPlan_Attr (Rst_OD) - set verbose : 3
2018.06.20 09:42:49 0: NEUTRINO Coolstream_WZ [NEUTRINO_Define] start device
2018.06.20 09:42:52 3: Webserver: new ext defined infix:jsf: dir:/opt/fhem/FHEM:
2018.06.20 09:42:52 3: Registering HTTPSRV Webserver for URL /jsf   and assigned link jsf ...
2018.06.20 09:42:53 1: Including ./log/fhem.save
2018.06.20 09:42:54 3: No I/O device found for THWR288A_22_1
2018.06.20 09:42:54 1: configfile: global: unknown attribute uniqueID. Type 'attr global ?' for a detailed list.

2018.06.20 09:42:55 3: FB_CALLMONITOR (Callmonitor) - found 3 phonebooks
2018.06.20 09:42:59 3: FB_CALLMONITOR (Callmonitor) - found 4 blocking rules (deflections)
2018.06.20 09:43:00 2: FB_CALLMONITOR (Callmonitor) - read 13 contacts from remote phonebook "x"
2018.06.20 09:43:01 2: FB_CALLMONITOR (Callmonitor) - read 231 contacts from remote phonebook "x"
2018.06.20 09:43:02 2: FB_CALLMONITOR (Callmonitor) - read 147 contacts from remote phonebook "x"
2018.06.20 09:43:02 3: WhatsApp: sending /disconnect
2018.06.20 09:43:02 3: WhatsApp: Disconnected
2018.06.20 09:43:02 2: WhatsApp: setting $HOME to /opt/fhem
2018.06.20 09:43:02 2: WhatsApp: starting yoswup-cli: /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup
2018.06.20 09:43:02 3: NTFY return:  WhatsApp:HASH(0x208d068)
2018.06.20 09:43:02 0: Featurelevel: 5.8
2018.06.20 09:43:02 0: Server started with 256 defined entities (fhem.pl:16866/2018-06-14 perl:5.020002 os:linux user:fhem pid:566)
2018.06.20 09:43:03 1: PERL WARNING: Use of uninitialized value in string ge at ./FHEM/95_holiday.pm line 161.
2018.06.20 09:43:03 3: telnetForBlockingFn_1529480583.41037: port 44779 opened
2018.06.20 09:43:03 3: CUL_HM set Jalo_Bad statusRequest
2018.06.20 09:43:03 1: HMLAN_Parse: hmusb new condition ok
/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py:1268: UserWarning: /opt/fhem/.python-eggs is writable by group/others and vulnerable to attack when used with get_resource_filename. Consider a more secure location (set with .set_extraction_path or the PYTHON_EGG_CACHE environment variable).
  warnings.warn(msg, UserWarning)
2018.06.20 09:43:05 3: Callmonitor device opened
2018.06.20 09:43:05 3: CUL_HM set Jalo_KIZI_hinten statusRequest
2018.06.20 09:43:05 3: WhatsApp: sending /L
2018.06.20 09:43:05 3: WhatsApp: sending /presence available
2018.06.20 09:43:05 2: LuftdatenInfo (Luftdaten_OD) - SDS011 position differs from other sensor position
2018.06.20 09:43:05 2: LuftdatenInfo (Luftdaten_Bra) - error while request: no data returned
2018.06.20 09:43:08 3: CUL_HM set Jalo_SchlafZi statusRequest
2018.06.20 09:43:09 3: CUL_HM set Jalo_SchlafZi_hinten statusRequest
2018.06.20 09:43:10 3: CUL_HM set Jalo_WZ_Seite statusRequest
2018.06.20 09:43:11 3: CUL_HM set Jalo_WZ_TV_vorne statusRequest

Offline amenomade

  • Hero Member
  • *****
  • Beiträge: 2624
Antw:komisches LOG Verhalten bei EINEM FHT Sensor
« Antwort #5 am: 20 Juni 2018, 11:48:04 »
Hmm. Ich habe jetzt k.A. mehr. Verschiebe mal dieses Thread nach dem SlowRF Subforum, vielleicht kriegst Du dort eine bessere Antwort. Laut maintainer.txt:
File                         Maintainer           Forum
=========================================================================
FHEM/11_FHT.pm               rudolfkoenig         SlowRF
FHEM 5.8 Pi 3, EchoDot, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, und HM Komponenten

F:"Schatz? Mach aus bitte"
M: "Alexa? Licht aus"-"Ich bin mir leider nicht sicher"  M:"Alexa? aus Licht"-"Das weiss ich leider nicht" M:"Alexa? Schalte...
F: "Drück mal auf den blöden Knopf!

Offline Thoffi1978

  • Full Member
  • ***
  • Beiträge: 371
Antw:komisches LOG Verhalten bei EINEM FHT Sensor
« Antwort #6 am: 20 Juni 2018, 13:46:54 »
Alles klar. Ich werde es versuchen.
Vielen Dank für die Antworten bis jetzt.

Hoffi

Offline AndreasHH

  • Jr. Member
  • **
  • Beiträge: 96
Antw:komisches LOG Verhalten bei EINEM FHT Sensor
« Antwort #7 am: 22 Juni 2018, 11:31:06 »
Moin,

hatte die Problematik auch, dass von den 6 FHT80B immer mal wieder 1-2 "weg waren", habe es dann, siehe enstsprechende WIKI-Einträge, über ein at gelöst.

Hintergrund: Wenn die FHT80B's über einen längeren Zeitraum keine Befehle von der Zentrale (FHEM) empfangen, werdenu.a.  keine Daten mehr in Richtung Zentrale gesendet.

hier mein at:
define fht_timeupdate_EGwz at *04:00:00 {if ($wday == 1) {fhem ("set FHT_EGwz time") } }
läuft so seit locker 2 - 3 Jahren problemlos.
Für jedes FHT80B ein at an unterschiedlichen Tagen.

Andreres mögliches Problem könnte die Frequenz sein (Es gibt da scheinbar leichte Streuungen bei den FHT80B's), evt. mal die CUL-Frequenz leicht verändern.

Gruß Andreas
FHEM 5.8, FB7490, FB7390, Linux-Server, Raspi 1, Raspi 2, FHEM2FHEM, div. FS20, div. FHT, div. HMS, div. Homematic, MQTT, ESP8266, Arduino

Offline Thoffi1978

  • Full Member
  • ***
  • Beiträge: 371
Antw:komisches LOG Verhalten bei EINEM FHT Sensor
« Antwort #8 am: 24 Juni 2018, 20:15:49 »
Hallo AndreasHH,

ich probiere die Lösung einmal aus.
Wenn ich das richtig Interpretiere, wird dadurch der FHT "angeschubst" und läuft wieder.


Trotzdem komisch, dass nur einer von drei das Verhalten ausweist.

Hoffi

Offline Thoffi1978

  • Full Member
  • ***
  • Beiträge: 371
Antw:komisches LOG Verhalten bei EINEM FHT Sensor
« Antwort #9 am: 28 Juni 2018, 07:58:53 »
Guten Morgen,

ein
set KiZi_Heizung timebringt leider kein Erfolg.

Erst wenn ich "DEF" drücke und gleich wieder "modify" wird der FHT Sensor erkannt.

Vielleicht hat jemand noch ein anderen Lösungsvorschlag.

Vielen Dank
Hoffi

Offline amenomade

  • Hero Member
  • *****
  • Beiträge: 2624
Antw:komisches LOG Verhalten bei EINEM FHT Sensor
« Antwort #10 am: 28 Juni 2018, 12:09:46 »
Erst wenn ich "DEF" drücke und gleich wieder "modify" wird der FHT Sensor erkannt.
Das finde ich komisch. Und dann läuft es problemlos bis zum nächsten Start?

Ich würde folgendes probieren:
- nachdem du auf Def und modify geklickt hast, dann noch anschliessend auf "save config". Wird es dann nach einem Neustart immer noch nicht erkannt?

- evtl. komplett löschen, und über das Kommandofeld in der WebUI neu anlegen (kein Copy/Paste von der jetzige Konfig in Raw Def, wirklisch "define KiZi_Heizung FHT ..." eintippen)
FHEM 5.8 Pi 3, EchoDot, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, und HM Komponenten

F:"Schatz? Mach aus bitte"
M: "Alexa? Licht aus"-"Ich bin mir leider nicht sicher"  M:"Alexa? aus Licht"-"Das weiss ich leider nicht" M:"Alexa? Schalte...
F: "Drück mal auf den blöden Knopf!

Offline Thoffi1978

  • Full Member
  • ***
  • Beiträge: 371
Antw:komisches LOG Verhalten bei EINEM FHT Sensor
« Antwort #11 am: 01 Juli 2018, 10:46:54 »
Hallo,

ich habe den Device gelöscht und neu definiert.

Nun läuft alles so wie es soll.

Vielen Dank für die Lösungsvorschläge.


Hoffi