shelly 2.5 mit mosquitto und mqtt2_client

Begonnen von Bastel-Frank, 22 August 2022, 07:47:17

Vorheriges Thema - Nächstes Thema

Bastel-Frank

Hallo zusammen,

ich möchte den shelly 2.5 über mosquitto (auf einer anderen IP) mit fhem verbinden und habe dabei Probleme:

1. Problem
Bei der Einrichtung von mqtt2_client mit Adresse auf mosquitto und anschließendem "autocreate = simple" stürzt fhem quasi sofort ab.

2. Problem
Wenn ich mqtt2_client ohne autocreate einrichte und dann mit mqtt2_device und das Template für shelly2.5 konfiguriere, dann kann ich den shelly aus fhem nicht steuern. Es scheint auch generell so zu sein, dass gar keine Verbindung zum shelly besteht.

Ich hoffe auf Eure Hilfe.

Viele Grüße
Frank

Beta-User

Zum Steuern: passt das IODev?
Zum "abstürzen": vermutlich zu viel Traffic auf dem mosquitto => FHEM kann das nicht schnell genug abarbeiten.
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatZum "abstürzen": vermutlich zu viel Traffic auf dem mosquitto => FHEM kann das nicht schnell genug abarbeiten.
Das haette ich gerne mit einem Auszug aus dem FHEM-Log nachgewiesen.

Bastel-Frank

Zitat von: rudolfkoenig am 22 August 2022, 09:29:59
Das haette ich gerne mit einem Auszug aus dem FHEM-Log nachgewiesen.

Auszug aus dem Log
2022.08.22 12:51:07 2: autocreate: define MQTT2_MQTT_Test_Client MQTT2_DEVICE MQTT_Test_Client MQTT_Test_Client
2022.08.22 12:51:07 2: autocreate: define FileLog_MQTT2_MQTT_Test_Client FileLog ./log/MQTT2_MQTT_Test_Client-%Y.log MQTT2_MQTT_Test_Client
Can't use an undefined value as a subroutine reference at ./FHEM/97_timerTS.pm line 86.
2022.08.22 12:51:07 1: Including fhem.cfg
2022.08.22 12:51:07 3: telnetPort: port 7072 opened
2022.08.22 12:51:07 3: WEB: port 8083 opened
2022.08.22 12:51:07 3: WEBphone: port 8084 opened
2022.08.22 12:51:07 3: WEBtablet: port 8085 opened
2022.08.22 12:51:07 2: eventTypes: loaded 9214 lines from ./log/eventTypes.txt
2022.08.22 12:51:07 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/97_timerTS.pm line 34, <$fh> line 88.
2022.08.22 12:51:07 1: PERL WARNING: Subroutine InternalTimer redefined at ./FHEM/97_timerTS.pm line 105, <$fh> line 88.
2022.08.22 12:51:07 1: PERL WARNING: Subroutine RemoveInternalTimer redefined at ./FHEM/97_timerTS.pm line 184, <$fh> line 88.
2022.08.22 12:51:07 2: TSCUL_condUpdateHM: CUL_KG new condition disconnected
2022.08.22 12:51:07 3: Opening CUL_KG device /dev/ttyACM0
2022.08.22 12:51:07 3: Setting CUL_KG serial parameters to 36800,8,N,1
2022.08.22 12:51:08 3: CUL_KG: Possible commands: ABCFGJKRUVWXYeilmtx
2022.08.22 12:51:09 1: CUL_KG is VERSION_TS, VTS 0.29 CUL868, CUL_V3.4
2022.08.22 12:51:09 2: TSCUL_condUpdateHM: CUL_KG new condition non-HM
2022.08.22 12:51:10 3: CUL_KG device opened
2022.08.22 12:51:10 2: TSCUL_condUpdateHM: CUL_KG new condition init
2022.08.22 12:51:10 2: Switched CUL_KG rfmode to HomeMatic
2022.08.22 12:51:10 2: TSCUL_condUpdateHM: CUL_EG new condition disconnected
2022.08.22 12:51:10 3: Opening CUL_EG device 192.168.178.24:2003
2022.08.22 12:51:11 3: CUL_EG: Possible commands: ABCFGJKRUVWXYeilmtx
2022.08.22 12:51:12 1: CUL_EG is VERSION_TS, VTS 0.29 CUL868, CUL_V3.4
2022.08.22 12:51:12 2: TSCUL_condUpdateHM: CUL_EG new condition non-HM
2022.08.22 12:51:13 3: CUL_EG device opened
2022.08.22 12:51:13 2: TSCUL_condUpdateHM: CUL_EG new condition init
2022.08.22 12:51:13 2: Switched CUL_EG rfmode to HomeMatic
2022.08.22 12:51:13 2: TSCUL_condUpdateHM: CUL_OG new condition disconnected
2022.08.22 12:51:13 3: Opening CUL_OG device 192.168.178.25:2003
2022.08.22 12:51:18 3: CUL_OG: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2022.08.22 12:51:19 1: CUL_OG is VERSION_TS, VTS 0.29 CSM868, nanoCUL_V1.x
2022.08.22 12:51:19 2: TSCUL_condUpdateHM: CUL_OG new condition non-HM
2022.08.22 12:51:20 3: CUL_OG device opened
2022.08.22 12:51:20 2: TSCUL_condUpdateHM: CUL_OG new condition init
2022.08.22 12:51:20 2: Switched CUL_OG rfmode to HomeMatic
2022.08.22 12:51:20 2: TSCUL_condUpdateHM: CUL_DG new condition disconnected
2022.08.22 12:51:20 3: Opening CUL_DG device 192.168.178.61:2003
2022.08.22 12:51:25 3: CUL_DG: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2022.08.22 12:51:26 1: CUL_DG is VERSION_TS, VTS 0.29 CSM868, nanoCUL_V1.x
2022.08.22 12:51:26 2: TSCUL_condUpdateHM: CUL_DG new condition non-HM
2022.08.22 12:51:27 3: CUL_DG device opened
2022.08.22 12:51:27 2: TSCUL_condUpdateHM: CUL_DG new condition init
2022.08.22 12:51:27 2: Switched CUL_DG rfmode to HomeMatic
2022.08.22 12:51:27 2: TSCUL_condUpdateHM: CUL_GH new condition disconnected
2022.08.22 12:51:27 3: Opening CUL_GH device 192.168.178.34:2003
2022.08.22 12:51:28 3: CUL_GH: Possible commands: ABCFGJKRUVWXYeilmtx
2022.08.22 12:51:29 1: CUL_GH is VERSION_TS, VTS 0.29 CUL868, CUL_V3.4
2022.08.22 12:51:29 2: TSCUL_condUpdateHM: CUL_GH new condition non-HM
2022.08.22 12:51:30 3: CUL_GH device opened
2022.08.22 12:51:30 2: TSCUL_condUpdateHM: CUL_GH new condition init
2022.08.22 12:51:30 2: Switched CUL_GH rfmode to HomeMatic
2022.08.22 12:51:30 2: TSCUL_condUpdateHM: CUL_AS new condition disconnected
2022.08.22 12:51:30 3: Opening CUL_AS device 192.168.178.36:4000
2022.08.22 12:51:35 3: CUL_AS: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2022.08.22 12:51:35 1: CUL_AS is VERSION_TS, VTS 0.29 CSM868, nanoCUL_V1.x
2022.08.22 12:51:36 2: TSCUL_condUpdateHM: CUL_AS new condition non-HM
2022.08.22 12:51:36 3: CUL_AS device opened
2022.08.22 12:51:36 2: TSCUL_condUpdateHM: CUL_AS new condition init
2022.08.22 12:51:36 2: Switched CUL_AS rfmode to HomeMatic
2022.08.22 12:51:36 3: myOWServer: OWNet version 3.1p5 loaded.
2022.08.22 12:51:36 3: myOWServer: Opening connection to OWServer 192.168.178.78:4304...
2022.08.22 12:51:36 3: myOWServer: Successfully connected to 192.168.178.78:4304.
2022.08.22 12:51:36 3: myOWServer: owserver version 3.2p4 found.
2022.08.22 12:51:36 3: myOWServer: No matching OWNet version found, using OWNet version 3.1p5.

Bastel-Frank

Zitat von: Beta-User am 22 August 2022, 09:02:53
Zum Steuern: passt das IODev?
Zum "abstürzen": vermutlich zu viel Traffic auf dem mosquitto => FHEM kann das nicht schnell genug abarbeiten.

IODev passt

rudolfkoenig

Da fuehlt sich timerTS unwohl.

Wir hatten vor drei Jahren hier: https://forum.fhem.de/index.php?topic=97159.0 eine Diskussion, womoeglich ist das Problem trotz anderslautenden Betreff noch nicht ganz geloest.

Ich empfehle ein ungepatchtes FHEM zu verwenden.

Bastel-Frank

Zitat von: rudolfkoenig am 22 August 2022, 13:17:05
Ich empfehle ein ungepatchtes FHEM zu verwenden.

Habe ich ein gepatchtes FHEM? Das ist mir neu  ???

rudolfkoenig

timerTS ist nicht Teil der FHEM-Distribution, siehe https://svn.fhem.de/trac/browser/trunk/fhem.
Das Modul ueberschreibt die PrioQueues Funktion, und das laut der verlinkten DIskussion nicht immer erfolgreich.

Bastel-Frank

Zitat von: rudolfkoenig am 22 August 2022, 14:09:21
timerTS ist nicht Teil der FHEM-Distribution, siehe https://svn.fhem.de/trac/browser/trunk/fhem.
Das Modul ueberschreibt die PrioQueues Funktion, und das laut der verlinkten DIskussion nicht immer erfolgreich.

Das wusste ich nicht, vielen Dank für deine Erläuterung.

noansi

Hallo Frank,

Du bist mit einem alten 97_timerTS.pm unterwegs. Darin ist es noch nicht abgefangen, dass ein undefinierter Funktionsaufruf in der PrioQueues zu so einem Absturz führen kann.

In der aktuellen ist es abgefangen. Steig auf die aktuelle Version um.

Gruß, Ansgar.

Bastel-Frank

Zitat von: noansi am 23 August 2022, 10:34:13
Hallo Frank,

Du bist mit einem alten 97_timerTS.pm unterwegs. Darin ist es noch nicht abgefangen, dass ein undefinierter Funktionsaufruf in der PrioQueues zu so einem Absturz führen kann.

In der aktuellen ist es abgefangen. Steig auf die aktuelle Version um.

Gruß, Ansgar.


Habe ich gemacht und siehe da, fhem bleibt online. Ich danke Euch Allen für Euren Support :)