In dieser Version sind folgende Ergänzungen, Änderungen und Fehlerbereinigungen enthalten:
1. environmentApp: Readings isSunny*, isWindy und isStormy hinzugefügt. Die Schwellwerte und Verzögerungszeiten können individuell über die Attribute brightness* und windSpeed* parameterisiert werden. Weiterhin kann das Reading dayNight nun entweder unmittelbar von Sensor gesteuert oder das Verhalten abhängig von der Helligkeit individuell festgelegt werden. Die Eltako Wetterdaten-Sendemodule unterstützen die dayNight-Funktion nicht. Deshalb sollte dann das Attribut brightnessDayNightCtrl auf custom gesetzt werden. Die Readings brightness, sun* haben jetzt einen Wertebereich von 0 lx bis 150 klx. Die Messwerte des Readings brightness entsprechen ab 1000 lx dem Maximalwert der Readings sunWest, sunSouth, sunEast. Die Readings sun* zeigen bis 999 lx den Messwert des brightness-Kanals an.
Das Profil hat nun zusätzlich den Betriebsmodul "master". In diesem Betriebsmodus werden EnOcean Telegramme mit Datum und Uhrzeit gesendet. Die Daten werden aus der Systemzeit abgeleitet. Das Uhrzeit-Telegramm kann periodisch versendet werden; standardmäßig alle 10 min. Mit Hilfe eines "inoffiziellen EEP" kann das Device definiert werden:
define <name> EnOcean ZZ-13-04 getNextID
Die Wetterdaten-Sendemodule von Eltako und AWAG nutzen die Wetterstationen der Firma Elsner. Die Wetterdaten werden dabei über eine RS485-Schnittstelle an die Sendemodule übertragen. Für die Elsner Wetterstationen gibt es nun die beiden Fhem-Module ElsnerWS https://fhem.de/commandref.html#ElsnerWS (https://fhem.de/commandref.html#ElsnerWS) und ModbusElsnerWS https://fhem.de/commandref.html#ModbusElsnerWS (https://fhem.de/commandref.html#ModbusElsnerWS). Funktional entsprechen diese dem environmentApp-Profil. Dabei werden die Wetterstationen direkt über einen RS485-USB-Transceiver an Fhem angeschlossen. Die Sendemodule entfallen somit. An dem RS485-Bus können mehrere Empfänger angeschaltet werden, sodass z. B. ein EnOcean-Sendemodul auch parallel mit einem RS485-USB-Transceiver betrieben werden kann.
2. PID-Regler: Funktionsaufrufe optimiert
ab V19607:
3. Modulkommunikation mit 00_TCM wurde geändert, um die Initialisierung der Module robuster zu machen. 00_TCM und 10_EnOcean müssen dafür mindestens die Version 19607 haben!
ab V19622:
4. isSunny*-, dayNight-Routinen geändert.
ab V19643 / V19651 / V19665
5. Generic Profiles V1.1 Anpassungen: teach-in signal type definition geändert, zusätziche data signal types und enumeration signal types hinzugefügt
ab V19718
6. Für das Profil manufProfile (Eltako shutter) kann jetzt über das Attribut calAtEndpoints beim dem Befehl set <name> position 0 oder set <name> position 100 ein Motorlauf mit der Fahrzeit shutTimeCloses ausgelöst werden. Damit ist sichergestellt, dass die Rollos immer in ihre Endpositionen fahren. Dies entspricht den Funktionen opens und closes.
ab V19820
7. Profile contact (EEP D5-00-01), lightTempOccupSensor.01 (EEP A5-08-01) für Zusatzdaten der Eltako Sensoren TK-BHSB, TF-FKB angepasst
ab V19848
8. Teach-In Funktionen des GP Profils geändert.
ab V19958 / 19971
9. neues Profil: multiFuncSensor.00 (EEP D2-15-00)
ab V19962
10. Kryptographische Funktionen: Prüfung des Rolling Codes verbessert
ab V20197:
11. SET-Command Routine geändert
ab V20346:
12. PID Routine geändert und ergänzt.
ab V20371:
13. Profil roomCtrlPanel.01 modifiziert (Wandbediengerät Thermokon EasySens SR06)
ab V20911:
14. lightSensor.01 (EEP A5-06-01): Unterscheidung zwischen verschiedenen Modellvarianten des Eltako Sensors FAH60 und ähnlichen eingeführt.
15. Remote Management: Ausgabewerte einiger Readings berichtigt
ab V20983:
16. Signal Telegramm: zusätzliche Funktionen ergänzt
ab V21239:
17. Profil multiFuncSensor.40 (EEP D2-14-40 - D2-14-41) für die multifunktionalen Sensoren EnOcean ST 550 / EMSIA bereitgestellt.
18. Verarbeitung der Ausgabe von Readings in Parse-Routine geändert.
ab V21291:
19. Security Funktionen um SEC_CDM und RLC 32 bit ergänzt.
20. CDM-Funktion modifiziert
ab V21679:
21. Profil blindsCrtl.00 blindsCrtl.01 geändert
ab V22529
22. Profil lightTempOccupSensor.01 geändert
ab V22531:
23. Profil actuator.01 (EEP D2-01-0C) geändert
ab V22876:
24. Profil environmentApp: windStrength Berechnung berichtigt, Readings umbennannt
ab V22959:
25: Die Namen der PID-Readings können den Routinen intern variable übergeben werden (Vorbereitung für später geplante Erweiterungen).
Einzelheiten sind in der commandref zu finden. Ich musste wieder an Änderungen an zentralen Routinen vornehmen. Bitte gründlich testen.
Hallo Klaus,
ich frage mich warum ich hier einen Dead Sensor Alarm bekomme, obwohl kurz zuvor noch empfangen wurde und das SignOfLife auf 300 konfiguriert ist:
2019-06-16_17:44:08 EnO_01A9124E C: open V: off E: 0 U: 2.92
2019-06-16_17:44:10 EnO_01A9124E brightness: 0
2019-06-16_17:44:10 EnO_01A9124E contact: closed
2019-06-16_17:44:10 EnO_01A9124E vibration: off
2019-06-16_17:44:10 EnO_01A9124E voltage: 2.92
2019-06-16_17:44:10 EnO_01A9124E C: closed V: off E: 0 U: 2.92
2019-06-16_17:49:12 EnO_01A9124E alarm: dead_sensor
Irgendeine Idee?
Besten Dank vorab!
Ne überhaupt keine Idee aber viele Fragezeichen. Ist auch etwas viel verlangt, wenn nur ein kurzer Auszug aus dem Standard-LOG-Eintrag vorliegt. Wie wäre es denn mit einem "list" und LOGs mit verbose = 5?
Leider aktuell nicht reproduzierbar. Ich mache das erweiterte Logfile wenn es nochmal auftritt.
Hallo Klaus,
seit der Änderung der beiden Module von Version:
$Id: 00_TCM.pm 19412 2019-05-20 04:03:49Z klaus.schauer
$Id: 10_EnOcean.pm 19413 2019-05-20 04:09:33Z klaus.schauer
auf (und neuer):
@19607 13.06.2019 08:06:53 klaus.schauer 00_TCM / 10_EnOcean: Communication between modules optimized. Both ...
lassen sich z.B. die beiden Aktoren FSR61-230V und FSB61-230V per FHEM2FHEM nicht mehr schalten.
Auf der Hauptinstanz wo die Raspberry Pi Erweiterungs-Platine EnOcean Pi Funkmodul angeschlossen ist, funktioniert alles weiterhin, jedoch nicht auf der zweiten Instanz von FHEM welche per FHEM2FHEM die Aktoren remote schalten soll.
Hauptinstanz wo die Raspberry Pi Erweiterungs-Platine EnOcean Pi Funkmodul angeschlossen ist:
Internals:
BaseID XXXXXXXX
CFGFN /opt/fhem/fhem.cfg
ChipID XXXXXXXX
DEF ESP3 /dev/ttyAMA0@57600
DeviceName /dev/ttyAMA0@57600
FD 13
FUUID 5c6d88c8-f33f-b3cf-98be-14bcc011ec43593b
LastID XXXXXXXX
MODEL ESP3
NAME TCM_ESP3_0
NOTIFYDEV global
NR 63
NTFY_ORDER 45-TCM_ESP3_0
PARTIAL
RSSI -73
STATE initialized
TYPE TCM
READINGS:
2017-07-18 17:12:49 baseID BaseID: XXXXXXXX RemainingWriteCycles: 0A
2018-11-10 15:42:52 frequencyInfo NOT_SUPPORTED
2019-06-27 12:17:12 maturity 01
2016-02-22 16:14:01 numSecureDev NOT_SUPPORTED
2019-06-27 12:17:12 repeater RepEnable: 00 RepLevel: 00
2019-06-27 12:17:12 state initialized
2019-06-27 12:17:12 version APIVersion: 02050000 APPVersion: 020A0000 ChipID: XXXXXXXX ChipVersion: XXXXXXXX Desc: GATEWAYCTRL
helper:
telegramSentTimeLast 1561630684.72033
awaitCmdResp:
Attributes:
baseID XXXXXXXX
room System
sendInterval 0
smartAckMailboxMax 0
Internals:
CFGFN /opt/fhem/fhem.cfg
DEF XXXXXXXX
FUUID 5c6d88d3-f33f-b3cf-626d-6e1dd4400dd6c9cc
IODev TCM_ESP3_0
LASTInputDev TCM_ESP3_0
MSGCNT 2
NAME EnO_switch_FSR61
NR 212
NTFY_ORDER 50-EnO_switch_FSR61
STATE BI
TCM_ESP3_0_DestinationID FFFFFFFF
TCM_ESP3_0_MSGCNT 2
TCM_ESP3_0_PacketType 1
TCM_ESP3_0_RSSI -73
TCM_ESP3_0_ReceivingQuality excellent
TCM_ESP3_0_RepeatingCounter 0
TCM_ESP3_0_SubTelNum 3
TCM_ESP3_0_TIME 2019-06-27 12:18:05
TYPE EnOcean
READINGS:
2019-06-27 12:18:05 buttons pressed
2019-06-27 12:18:05 channelB BI
2019-06-27 12:18:05 state BI
helper:
Attributes:
IODev TCM_ESP3_0
alias OG_Kueche_Esstisch_Lampe
devStateIcon B0:li_wht_on BI:li_wht_off
eventMap /BI released:on/B0 released:off/
group Licht
manufID 7FF
room EnOcean,Küche
subType switch
Zweite Instanz (Remote-FHEM):
Internals:
BaseID 00000000
CFGFN /opt/fhem/fhem.cfg
DEF ESP3 none
DeviceName none
FUUID 5c558342-f33f-5f35-6ec6-a6e1112260d5c7e7
LastID 00000000
MODEL ESP3
NAME TCM_ESP3_0
NOTIFYDEV global
NR 59
NTFY_ORDER 45-TCM_ESP3_0
PARTIAL
STATE initialized
TYPE TCM
READINGS:
2018-11-10 15:42:52 frequencyInfo NOT_SUPPORTED
2019-06-27 12:17:41 state initialized
2018-11-10 15:43:05 version APIVersion: 02050000 APPVersion: 020A0000 ChipID: XXXXXXXX ChipVersion: XXXXXXXX Desc: GATEWAYCTRL
helper:
Attributes:
dummy 1
icon cul
learningMode demand
room System
sendInterval 0
smartAckMailboxMax 0
Internals:
CFGFN /opt/fhem/fhem.cfg
Clients :EnOcean:
DEF 192.168.111.40:7072 RAW:TCM_ESP3_0
FD 13
FUUID 5c558342-f33f-5f35-4ebf-fc3570475cde641a
Host 192.168.111.40:7072
NAME Remoteserver_fhem_01_RAW_TCM_ESP3_0
NR 61
PARTIAL
STATE connected
TYPE FHEM2FHEM
informType RAW
rawDevice TCM_ESP3_0
MatchList:
1:EnOcean ^EnOcean:
helper:
cdmSeq 1
Attributes:
icon cul
room FHEM2FHEM
Logs mit verbose 5 kann ich dir gerne liefern, jedoch Frage ich mich, was du benötigst und in welcher Rheinfolge?
Viele Grüße,
Mikka
In der zweiten Instanz ist die Definition der BaseID falsch, warum auch immer. In der neuen Version werden die SenderIDs umfassender überprüft und Telegramme von Devices mit u. a. 0000000 verworfen. Telegramme mit einer SenderID 0000000 führen dazu, dass diese Telegramme mit der ChipID rausgehen. Da führt zu problematischen Seiteneffekten. Bitte gültige SenderIDs aus dem BaseID-Bereich des Transceivers vergeben.
Hallo Klaus,
danke für den Tipp. Habe ich angepasst doch leider bleibt das Ergebnis gleich, kein schalten möglich :-\
Hast du sonst noch Ideen? Wie kann ich beim debuggen helfen?
Viele Grüße,
Mikka
Sobald die SenderID geändert wird, muss das Fhem-Device im Aktor neu eingelernt werden. Für eine weitere Fehlereingrenzung werden neben den Device-Lists inkl. der verwendeten SenderIDs auch die LOGs mit verbose 5 von beiden Installationen benötigt.
Ich versehe auch nicht, warum die baseID manuell per Attribut festgelegt wurde. Das geht doch viel einfacher über die automatische Zuweisung beim Start.
Ergänzung:
Bitte mit geändertem TCM-Modul testen, ob die Funktion damit wieder gegeben ist. Eine neue zusätzliche Abfrage ist dort deaktiviert.
Leider ändert sich der Zustand mit dem geändertem TCM-Modul nicht.
Benötigst du die Logs auch in der Version wo alles funktioniert (also $Id: 00_TCM.pm 19412 und $Id: 10_EnOcean.pm 19413)?
Und auf welcher nicht funktionierenden Version soll ich die weiteren LOGs erstellen (die aktuellen Versionen in FHEM + den Anhang hier)?
Viele Grüße,
Mikka
Zitat von: klaus.schauer am 28 Juni 2019, 06:29:34
Ich versehe auch nicht, warum die baseID manuell per Attribut festgelegt wurde. Das geht doch viel einfacher über die automatische Zuweisung beim Start.
Da ich auch mal mit dem EnOcean USB 300 USB-Stick und einer Raspberry Pi Erweiterungs-Platine herum probiert/experimentiert habe, hatte ich die baseID per Hand gesetzt um diese zu erzwingen...
Auf dem Hauptsystem kann ich das Attribut gerne löschen, jedoch muss man in der zweiten Instanz ja nun was angeben.
Zitat von: Mikka am 28 Juni 2019, 10:52:21
Benötigst du die Logs auch in der Version wo alles funktioniert (also $Id: 00_TCM.pm 19412 und $Id: 10_EnOcean.pm 19413)?
Und auf welcher nicht funktionierenden Version soll ich die weiteren LOGs erstellen (die aktuellen Versionen in FHEM + den Anhang hier)?
LOGs auf Basis der aktuell veröffentlichen Version reichen.
Hallo Klaus,
sorry für meine späte Meldung. Ich hoffe ich habe mit den Logfiles alles richtig gemacht und du kannst mit diesen etwas anfangen.
FHEM-Master = cube
FHEM-Slave = fhem-01
Viele Grüße,
Mikka