Hauptmenü

Neueste Beiträge

Seiten 1 ... 4 5 6 7 8 ... 10
#51
Sonstiges / Aw: FileLog liefert mit CURREN...
Letzter Beitrag von noansi - 30 August 2025, 21:57:52
Hallo Rudolf,

ok, vermutlich zu unpräzise.

Ausgangspunkt ist ein FileLog. Zu dem FileLog ist nur das Attribut logtype mit einem gplot File und text gesetzt (ok, als einziges weiteres Attribut auch noch room, aber das ist hier unerheblich).

FileLog präsentiert mir nun Monatslogs von Januar bis August mit Weblinks für Plot und Text.
Klicke ich auf einen Plot Link, z.B. vom Mai dann wird der Plot für August geöffnet in Tagesansicht heute. Das ist die erste Merkwürdigkeit aus Nutzersicht, denn der angeklickte Monatsplot hat nichts mit dem zu tun, was angezeigt wird, es sei denn, man klickt auf den aktuellen Monat (was ich für gewöhnlich tue). Wenn ich auf den Textlink klicke, dann wird das Log für Mai auch in Textform angezeigt, also der Erwartung entsprechend.

Es wird bei den Plots der aktuelle Tag angezeigt, egal welches der Monatslogs angeklickt wird.

Zoome ich diesen Plot nur raus bis zur Jahresansicht, dann wird in der Jahresansicht der Januar angezeigt. Während des schrittweisen Rauszoomens bis zur Monatsansicht jedoch noch der August. Und dieser Monatsansichtswechsel von August nach Januar ist richtig verwirrend.

ZitatMeine Hypothese: FHEM laeuft seit Januar, die letzten Daten wurden in Februar in die Datei geschrieben, und wenn man jetzt ein Monatslog anschauen will, dann werden Februar-Daten geliefert.
Ich vermute, du glaubst, ich hätte ein SVG device erstellt. Habe ich aber nicht, sondern nur das LogFile device, weil ich mehr normalerweise nicht brauche.
Und nein, wie oben beschrieben. Monatslogs liegen von Januar bis zum aktuellen August vollständig im log Verzeichnis.

SVG_getData ruft in diesem Fall des Monatsplots FileLog_Get mit Infile 'CURRENT' auf, da LogFile kein Internal LOGDEVICE und FILELOG hat.
from jedoch mit dem Anfang der Plotansicht (Zoom), was bei Jahresansicht nunmal beim 1.1. los geht. Und damit liefert FileLog_Get die Januar Daten, die dann im Jahresplot angezeigt werden, nach der Rauszoomvorgeschichte unerwartet.

Viele Grüße, Ansgar.
#52
FHEM Code changes / Revision 30233: 76_SolarForeca...
Letzter Beitrag von System - 30 August 2025, 21:50:47
Revision 30233: 76_SolarForecast: contrib V1.58.0

76_SolarForecast: contrib V1.58.0

Source: Revision 30233: 76_SolarForecast: contrib V1.58.0
#53
Automatisierung / AutoShutterControl in HomeAss...
Letzter Beitrag von Beetle2003 - 30 August 2025, 21:44:30
Hallo,

ich nutze das ASC Modul seit vielen Jahren in Fhem und bin sehr zufrieden.
Da ich alle meine Anwendungen in HomeAssistant überführen möchte, suche ich nach einer Lösung für meine Rollos.
Hat jemand dieses oder ein ähnliches Modul in HomeAssistant?
Wie und wo kann es bezogen werden?

Vielen Dank für die Hilfestellung.

Gruss
#54
Sonstiges / Timing ModbusAttr Abfrage für ...
Letzter Beitrag von FhemPiUser - 30 August 2025, 21:30:10
Hallo,

ich nutze das tolle Modul ModbusAttr, um einen Sungrow SH10RT Wechselrichter abzufragen, habe aber immer wieder Timingprobleme.

Laut eines Users im Photovoltaikforum, schließt der Wechselrichter die Verbindung sobald mehr als ca 20-100ms zwischen Requests vergangen sind (siehe
https://www.photovoltaikforum.com/thread/170810-sungrow-hat-probleme-mit-der-modbus-verbindung/?postID=2660675#post2660675). Blöde Implementierung im Wechselrichter, aber kann man leider nicht ändern.

Daher die Frage: Gibt es eine Möglichkeit sicherzustellen, dass nie mehr als ca. 20-100ms zwischen Requests vergehen?

Ich habe im Modul bereits einige Timing-Attribute dafür gesetzt:

Da fhem nicht echtzeitfähig ist, kann man das vermutlich nicht 100%ig sicherstellen. Aber kann man irgendwie Blockierungen des ModbusAttr-Devices durch andere fhem-Prozesse/-devices verhindern, z.B. durch Priorisierung des ModbusAttr-Devices oder durch einen parallelen dedizierten Thread?

Danke
#55
ZWave / Aw: Migration des Netzwerks vo...
Letzter Beitrag von fireball - 30 August 2025, 21:22:33
kleines AddOn, weiß nicht obs von Bedeutung ist, so hat FHEM einmal den Stick neu angelegt, hatte das Device aber dann wieder gelöscht.

Code Auswählen
2025.08.30 19:55:23 3: Opening ZWDongle_1 device /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00C3805E-if01-port0
2025.08.30 19:55:23 3: Setting ZWDongle_1 serial parameters to 115200,8,N,1
2025.08.30 19:55:26 3: ZWDongle_1 device opened
2025.08.30 19:55:28 1: /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00C3805E-if01-port0 disconnected, waiting to reappear (ZWDongle_1)
2025.08.30 19:55:28 3: Setting ZWDongle_1 serial parameters to 115200,8,N,1
2025.08.30 19:55:28 1: /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00C3805E-if01-port0 disconnected, waiting to reappear (ZWDongle_1)
2025.08.30 19:55:28 1: ZWDongle_ReadAnswer: no data read
2025.08.30 19:55:28 1: /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00C3805E-if01-port0 reappeared (ZWDongle_1)
So zeigt ZWaveUI JS die Konfig an des 10pro an:
Code Auswählen
{
  "id": 1,
  "name": "",
  "loc": "",
  "values": [],
  "groups": [],
  "neighbors": [],
  "ready": true,
  "available": true,
  "hassDevices": {},
  "failed": false,
  "inited": true,
  "eventsQueue": [
    {
      "time": "2025-08-30T19:21:50.510Z",
      "event": "alive",
      "args": [
        0
      ]
    },
    {
      "time": "2025-08-30T19:21:50.560Z",
      "event": "ready",
      "args": []
    },
    {
      "time": "2025-08-30T19:21:50.560Z",
      "event": "ready",
      "args": []
    }
  ],
  "status": "Alive",
  "interviewStage": "Complete",
  "priorityReturnRoute": {},
  "customReturnRoute": {},
  "customSUCReturnRoutes": [],
  "applicationRoute": false,
  "hexId": "0x0371 0x0004-0x003c",
  "dbLink": "https://devices.zwave-js.io/?jumpTo=0x0371:0x0004:0x003c:7.23.2",
  "manufacturerId": 881,
  "productId": 60,
  "productType": 4,
  "deviceConfig": {
    "filename": "/usr/src/app/store/.config-db/devices/0x0371/zwa060.json",
    "isEmbedded": true,
    "manufacturer": "Aeotec Ltd.",
    "manufacturerId": 881,
    "label": "ZWA060",
    "description": "Z-Stick 10 Pro",
    "devices": [
      {
        "productType": 4,
        "productId": 60
      }
    ],
    "firmwareVersion": {
      "min": "0.0",
      "max": "255.255"
    },
    "preferred": false
  },
  "productLabel": "ZWA060",
  "productDescription": "Z-Stick 10 Pro",
  "manufacturer": "Aeotec Ltd.",
  "firmwareVersion": "7.23.2",
  "sdkVersion": "7.23.2",
  "protocolVersion": 3,
  "endpointsCount": 0,
  "endpoints": [
    {
      "index": 0,
      "label": "Root Endpoint",
      "deviceClass": {
        "basic": 2,
        "generic": 2,
        "specific": 1
      }
    }
  ],
  "supportsSecurity": false,
  "supportsBeaming": true,
  "isControllerNode": true,
  "isListening": true,
  "isFrequentListening": false,
  "isRouting": true,
  "keepAwake": false,
  "maxDataRate": 100000,
  "deviceClass": {
    "basic": 2,
    "generic": 2,
    "specific": 1
  },
  "lastActive": 1756581722034,
  "firmwareCapabilities": {
    "firmwareUpgradable": false
  },
  "protocol": 0,
  "deviceId": "881-60-4",
  "hasDeviceConfigChanged": false,
  "rfRegions": [
    {
      "value": 2,
      "title": "Australia/New Zealand",
      "disabled": false
    },
    {
      "value": 8,
      "title": "China",
      "disabled": false
    },
    {
      "value": 11,
      "title": "Europe (Long Range)",
      "disabled": false
    },
    {
      "value": 3,
      "title": "Hong Kong",
      "disabled": false
    },
    {
      "value": 5,
      "title": "India",
      "disabled": false
    },
    {
      "value": 6,
      "title": "Israel",
      "disabled": false
    },
    {
      "value": 32,
      "title": "Japan",
      "disabled": false
    },
    {
      "value": 33,
      "title": "Korea",
      "disabled": false
    },
    {
      "value": 7,
      "title": "Russia",
      "disabled": false
    },
    {
      "value": 9,
      "title": "USA (Long Range)",
      "disabled": false
    }
  ],
  "supportsLongRange": true,
  "supportsTime": false,
  "_name": "NodeID_1",
  "statistics": {
    "messagesTX": 45,
    "messagesRX": 90,
    "messagesDroppedRX": 7,
    "NAK": 0,
    "CAN": 0,
    "timeoutACK": 0,
    "timeoutResponse": 0,
    "timeoutCallback": 0,
    "messagesDroppedTX": 0
  },
  "prioritySUCReturnRoute": false,
  "lastReceive": 1756581722034,
  "lastTransmit": 1756581722034,
  "errorReceive": false,
  "errorTransmit": false,
  "powerlevel": -11.6,
  "measured0dBm": -0.1,
  "RFRegion": 11,
  "maxLongRangePowerlevel": 14
}
letztes Update für heute:

Kann es sein, dass die FHEM die ZWAVE API nicht richtig implementiert?!
Wenn ich mir diese Zeile im Log anschaue:
2025.08.30 20:13:36 4: ZWDongle_ReadAnswer for homeId: 0120ec4154d20001
dann sehe ich nach der 0120 die HomeID:ec4154d und dann kommt die NodeID: 0001

Wie die 0001 jetzt interpretiert wird ist mir nicht klar, aber mit nem Hex-Umrechner komme ich auf ne 1.

VG
René
#56
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 30 August 2025, 21:10:20
@Parallix, @all,

ich habe eine Prototyplösung zu dem ab #3840 diskutierten Thema gebaut und als V 1.58.0 in mein contrib geladen.
Die optimale (bzw. Mindest-) Ladeleistung für die aktuelle Stunde wird im Reading Battery_ChargeOptTargetPower_XX für jede Batterie getrennt vorgeschlagen. Dieser Wert ändert sich dynamisch und liefert die (optimale) Mindestladeleistung mit der bei Eintritt der zugrunde gelegten Vorhersagen am Ende des Tages der maximal mögliche SoC (wahrscheinlich) erreicht wird.

Mit ctrlDebug 'batteryManagement' sieht man die prognostizierte Entwicklung.

Code Auswählen
2025.08.30 12:02:15.219 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 13, Start SoC: 17991 Wh, Surplus: 3572 Wh, OptTargetPower: 3572 W
2025.08.30 12:02:15.219 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 14, Start SoC: 19678 Wh, Surplus: 1874 Wh, OptTargetPower: 1748 W
2025.08.30 12:02:15.220 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 15, Start SoC: 21426 Wh, Surplus: 4048 Wh, OptTargetPower: 4048 W
2025.08.30 12:02:15.220 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 16, Start SoC: 25960 Wh, Surplus: 2932 Wh, OptTargetPower: 614 W
2025.08.30 12:02:15.220 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 17, Start SoC: 26574 Wh, Surplus: 3441 Wh, OptTargetPower: 614 W
2025.08.30 12:02:15.221 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 18, Start SoC: 28416 Wh, Surplus: 1441 Wh, OptTargetPower: 0 W
2025.08.30 12:02:15.221 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 19, Start SoC: 28416 Wh, Surplus: 82 Wh, OptTargetPower: 0 W

Wenn alles funktioniert, würde ich die zukünftigen optTarget Zielwerte in nextHours integrieren. Dadurch können sie neben dem genannten Reading für eigene Steuerungen ausgelesen und verwendet werden.

LG,
Heiko
#57
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 30 August 2025, 21:09:02
Das Setzen eines Attributwertes ist auch nur eine Hash-Aktion. Allerdings, und das ist vermutlich der Grund, wird das geänderte Attribut jedesmal im Filesystem / configDB persistiert. Deswegen der Hinweis, nicht das z.B. alle 2 Sek. ein Speichervorgang angetriggert wird. Vllt. sogar öfter mit einem notify o.ä.
#58
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Parallix - 30 August 2025, 20:54:55
Zitat von: DS_Starter am 30 August 2025, 20:34:59Guten Abend zusammen,

@Parallix,

ZitatAus meiner Regelung heraus wird das SF-Attribut "loadAbort" zyklisch via "set ... attrKeyVal ..." neu gesetzt, eigentlich nur "MinPwr". Dieses zyklische Setzen führt zu einer erheblichen Systemlast, die auch durch Einschalten des "Silent Mode" nicht reduziert werden kann.
Über welche Logik setzt du attrKeyVal? Das gesetzte Attribut wird ja auf Filesystemebene gespeichert. Man sollte dafür Sorge tragen, dass nur dann ein attrKeyVal ausgeführt wird wenn wirklich eine Änderung eines Parameters erfolgen soll und z.B. nicht einfach setzen auch wenn der Param immer gleich bleibt.

Nutze das Attribut MinPwr wie vorgesehen im Kontext "Ladeschlussleistung".

Darüber hinaus nutze ich es auch, um auf einfache Weise meinen BAT-Controller mit der Info zu versorgen, wie lange er noch bis Tagesende mit > MinPwr laden kann. Die andere Logik (siehe wenige Seiten zuvor) ist ja noch nicht da. Bis dahin muss der Attributwert für den Attributteil "MinPwr" von meinem Bat-Controller permanent an die aktuelle Situation (aktueller SOC) angepasst werden; das natürlich nur dann, wenn es ein vom alten Wert abweichendes MinPwr gibt. Bei Readings führt eine solche Anpassung von Werten zu keinem Problem in Bezug auf die Systembelastung, wohl aber bei Attributen. Über die Attribut-Hashes könnte ich das Performance-Problem wahrscheinlich lösen, vermute aber, dass das keine saubere Lösung ist und bin daher hier auf der Suche.
#59
ZWave / Aw: Migration des Netzwerks vo...
Letzter Beitrag von fireball - 30 August 2025, 20:51:35
Hi Rudolf,

hier nochmal eine Zusammenfassung und die gewünschten Ergebnisse:

alter Gen5 Aeotec - Stick:
- HomeId:ec4154d2 CtrlNodeIdHex:01
- version Z-Wave 3.95 STATIC_CONTROLLER

Migration von Gen5 via Aeotec BackupTool auf
"neuen" Gen5+ Aeotec - Stick:
- HomeId:ec4154d2 CtrlNodeIdHex:01
- version Z-Wave 6.07 STATIC_CONTROLLER

Migration von Gen5+ via ZWaveUI JS Backup/Restore auf
"nagelneuen" 10 Pro Aeotec - Stick
- HomeId:ec4154d2 CtrlNodeIdHex:01
- version Z-Wave 7.23 BRIDGE_CONTROLLER

Funktion in FHEM:
Gen5  : alles läßt sich wie gewohnt schalten - /dev/serial/by-id/usb-0658_0200-if00@115200
Gen5+ : alles läßt sich wie gewohnt schalten - /dev/serial/by-id/usb-0658_0200-if00@115200
10pro : es läßt sich nichts schalten, Stick antwortet aber - /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00C3805E-if01-port0@115200

Funktion in HomeAssistant:
10pro : alles läßt sich wie gewohnt schalten - /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_00C3805E-if01-port0@115200

Sowohl in ZWaveUI JS in HomeAssistant, als auch ZWaveUI JS in einem testweise angelegten DockerContainer:
10pro wird mit ID 1 ausgelesen (ZwaveUI_JS_@HA.png, ZwaveUI_JS_@Docker.png)

HomeAssistant selber:
10pro wird mit ID 1 angezeigt (Zwave_10Pro_as_device@HA.png)

Mit dem Zwave PC ControllerTool aus dem Simplycity Studio unter Windows:
10pro wird mit ID 1 ausgelesen (10pro_pc_controller2.png)

verbose 5 mit 10pro:
get homeID und get version
Code Auswählen
2025.08.30 20:13:36 4: ZWDongle *** get ZWDongle_2 homeId
2025.08.30 20:13:36 5: ZWDongle_Write 0020 ()
2025.08.30 20:13:36 5: DevIo_SimpleWrite ZWDongle_2: 01030020dc
2025.08.30 20:13:36 4: ZWDongle_ReadAnswer arg:homeId regexp:^0120
2025.08.30 20:13:36 4: ZWDongle_Read ZWDongle_2: rcvd 0120ec4154d20001 (answer MEMORY_GET_ID), sending ACK
2025.08.30 20:13:36 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:13:36 4: ZWDongle_ReadAnswer for homeId: 0120ec4154d20001
2025.08.30 20:13:38 4: ZWDongle_Read ZWDongle_2: rcvd 00a8000001002b0631050422000300a9007f7f (request ZW_APPLICATION_COMMAND_HANLDER_BRIDGE), sending ACK
2025.08.30 20:13:38 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:13:38 5: ZWDongle_2: dispatch 00a8000001002b0631050422000300a9007f7f
2025.08.30 20:13:38 4: CMD:ZW_APPLICATION_COMMAND_HANLDER_BRIDGE ID:00 ARG:01002b0631050422000300a9007f7f CB:00
2025.08.30 20:13:38 4: ZWave: unknown message 00a8000001002b0631050422000300a9007f7f for ID 01


2025.08.30 20:15:19 4: ZWDongle *** get ZWDongle_2 version
2025.08.30 20:15:19 5: ZWDongle_Write 0015 ()
2025.08.30 20:15:19 5: DevIo_SimpleWrite ZWDongle_2: 01030015e9
2025.08.30 20:15:19 4: ZWDongle_ReadAnswer arg:version regexp:^0115
2025.08.30 20:15:19 4: ZWDongle_Read ZWDongle_2: rcvd 01155a2d5761766520372e32330007 (answer ZW_GET_VERSION), sending ACK
2025.08.30 20:15:19 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:15:19 4: ZWDongle_ReadAnswer for version: 01155a2d5761766520372e32330007
hier noch ein bisl Traffic:
Code Auswählen
2025.08.30 20:14:27 4: ZWave: unknown message 00a8000001002b0631050422000000a9007f7f for ID 01
2025.08.30 20:14:28 4: ZWDongle_Read ZWDongle_2: rcvd 00a8000001002b0631050422000300a9007f7f (request ZW_APPLICATION_COMMAND_HANLDER_BRIDGE), sending ACK
2025.08.30 20:14:28 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:14:28 5: ZWDongle_2: dispatch 00a8000001002b0631050422000300a9007f7f
2025.08.30 20:14:28 4: CMD:ZW_APPLICATION_COMMAND_HANLDER_BRIDGE ID:00 ARG:01002b0631050422000300a9007f7f CB:00
2025.08.30 20:14:28 4: ZWave: unknown message 00a8000001002b0631050422000300a9007f7f for ID 01
2025.08.30 20:14:31 4: ZWDongle_Read ZWDongle_2: rcvd 00a8000001002b0631050422000000a9007f7f (request ZW_APPLICATION_COMMAND_HANLDER_BRIDGE), sending ACK
2025.08.30 20:14:31 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:14:31 5: ZWDongle_2: dispatch 00a8000001002b0631050422000000a9007f7f
2025.08.30 20:14:31 4: CMD:ZW_APPLICATION_COMMAND_HANLDER_BRIDGE ID:00 ARG:01002b0631050422000000a9007f7f CB:00
2025.08.30 20:14:31 4: ZWave: unknown message 00a8000001002b0631050422000000a9007f7f for ID 01
2025.08.30 20:14:32 4: ZWDongle_Read ZWDongle_2: rcvd 00a8000001002b0631050422000300a9007f7f (request ZW_APPLICATION_COMMAND_HANLDER_BRIDGE), sending ACK
2025.08.30 20:14:32 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:14:32 5: ZWDongle_2: dispatch 00a8000001002b0631050422000300a9007f7f
2025.08.30 20:14:32 4: CMD:ZW_APPLICATION_COMMAND_HANLDER_BRIDGE ID:00 ARG:01002b0631050422000300a9007f7f CB:00
2025.08.30 20:14:32 4: ZWave: unknown message 00a8000001002b0631050422000300a9007f7f for ID 01
2025.08.30 20:14:33 4: ZWDongle_Read ZWDongle_2: rcvd 00a8000001002b0631050422000000a9007f7f (request ZW_APPLICATION_COMMAND_HANLDER_BRIDGE), sending ACK
2025.08.30 20:14:33 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:14:33 5: ZWDongle_2: dispatch 00a8000001002b0631050422000000a9007f7f
2025.08.30 20:14:33 4: CMD:ZW_APPLICATION_COMMAND_HANLDER_BRIDGE ID:00 ARG:01002b0631050422000000a9007f7f CB:00
2025.08.30 20:14:33 4: ZWave: unknown message 00a8000001002b0631050422000000a9007f7f for ID 01
2025.08.30 20:14:34 4: ZWDongle_Read ZWDongle_2: rcvd 00a8000001002b0631050422000400a9007f7f (request ZW_APPLICATION_COMMAND_HANLDER_BRIDGE), sending ACK
2025.08.30 20:14:34 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:14:34 5: ZWDongle_2: dispatch 00a8000001002b0631050422000400a9007f7f
2025.08.30 20:14:34 4: CMD:ZW_APPLICATION_COMMAND_HANLDER_BRIDGE ID:00 ARG:01002b0631050422000400a9007f7f CB:00
2025.08.30 20:14:34 4: ZWave: unknown message 00a8000001002b0631050422000400a9007f7f for ID 01
2025.08.30 20:14:40 4: ZWDongle_Read ZWDongle_2: rcvd 00a8000001002b0631050422000500a9007f7f (request ZW_APPLICATION_COMMAND_HANLDER_BRIDGE), sending ACK
2025.08.30 20:14:40 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:14:40 5: ZWDongle_2: dispatch 00a8000001002b0631050422000500a9007f7f
2025.08.30 20:14:40 4: CMD:ZW_APPLICATION_COMMAND_HANLDER_BRIDGE ID:00 ARG:01002b0631050422000500a9007f7f CB:00
2025.08.30 20:14:40 4: ZWave: unknown message 00a8000001002b0631050422000500a9007f7f for ID 01
2025.08.30 20:14:41 4: ZWDongle_Read ZWDongle_2: rcvd 00a8000001002b0631050422000000a9007f7f (request ZW_APPLICATION_COMMAND_HANLDER_BRIDGE), sending ACK
2025.08.30 20:14:41 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:14:41 5: ZWDongle_2: dispatch 00a8000001002b0631050422000000a9007f7f
2025.08.30 20:14:41 4: CMD:ZW_APPLICATION_COMMAND_HANLDER_BRIDGE ID:00 ARG:01002b0631050422000000a9007f7f CB:00
2025.08.30 20:14:41 4: ZWave: unknown message 00a8000001002b0631050422000000a9007f7f for ID 01
2025.08.30 20:14:43 4: ZWDongle_Read ZWDongle_2: rcvd 00a8000001002b0631050422000400a9007f7f (request ZW_APPLICATION_COMMAND_HANLDER_BRIDGE), sending ACK
2025.08.30 20:14:43 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:14:43 5: ZWDongle_2: dispatch 00a8000001002b0631050422000400a9007f7f
2025.08.30 20:14:43 4: CMD:ZW_APPLICATION_COMMAND_HANLDER_BRIDGE ID:00 ARG:01002b0631050422000400a9007f7f CB:00
2025.08.30 20:14:43 4: ZWave: unknown message 00a8000001002b0631050422000400a9007f7f for ID 01
2025.08.30 20:14:44 4: ZWDongle_Read ZWDongle_2: rcvd 00a8000001002b0631050422000600a9007f7f (request ZW_APPLICATION_COMMAND_HANLDER_BRIDGE), sending ACK
2025.08.30 20:14:44 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:14:44 5: ZWDongle_2: dispatch 00a8000001002b0631050422000600a9007f7f
2025.08.30 20:14:44 4: CMD:ZW_APPLICATION_COMMAND_HANLDER_BRIDGE ID:00 ARG:01002b0631050422000600a9007f7f CB:00
2025.08.30 20:14:44 4: ZWave: unknown message 00a8000001002b0631050422000600a9007f7f for ID 01
2025.08.30 20:14:45 4: ZWDongle_Read ZWDongle_2: rcvd 00a8000001002b0631050422000000a9007f7f (request ZW_APPLICATION_COMMAND_HANLDER_BRIDGE), sending ACK
2025.08.30 20:14:45 5: DevIo_SimpleWrite ZWDongle_2: 06
2025.08.30 20:14:45 5: ZWDongle_2: dispatch 00a8000001002b0631050422000000a9007f7f
2025.08.30 20:14:45 4: CMD:ZW_APPLICATION_COMMAND_HANLDER_BRIDGE ID:00 ARG:01002b0631050422000000a9007f7f CB:00
2025.08.30 20:14:45 4: ZWave: unknown message 00a8000001002b0631050422000000a9007f7f for ID 01

Was mich noch wundert... beim durchschauen des fhem.log beim Start sehe ich noch einen Versuch, einen ZWDongle auf /dev/serial0 zu finden.
Das war viell. mal vor 100 Jahren so konfiguriert, bevor ich auf /dev/serial/by-id/usb-0658_0200-if00@115200 umgestellt hatte.
Aber man sieht, dass FHEM einen ZWDongle auf /dev/serial0 sucht und Opening ZWDongle_2 device /dev/ttyUSB2 anlegt.

Woher das kommt keine Ahnung, es gibt kein ZWDongle in der fhem.cfg


Code Auswählen
2025.08.30 20:17:10 3: LGTV_WebOS (WohnzimmerTV2) - defined with host 192.168.178.227
2025.08.30 20:17:10 3: LGTV_WebOS (WohnzimmerTV2) - disabled
2025.08.30 20:17:11 3: Opening ZWDongle_2 device /dev/ttyUSB2
2025.08.30 20:17:11 3: Setting ZWDongle_2 serial parameters to 115200,8,N,1
2025.08.30 20:17:12 3: ZWDongle_2 device opened
2025.08.30 20:17:12 1: Including ./log/fhem.save
2025.08.30 20:17:12 3: No I/O device found for AEON_MultiSensor
2025.08.30 20:17:12 3: No I/O device found for FSensor_OG_GZ_S
2025.08.30 20:17:12 3: No I/O device found for FSensor_EG_WZ_T_S
2025.08.30 20:17:12 3: No I/O device found for BM_OG_Flur01
2025.08.30 20:17:12 3: No I/O device found for GB_Kreis_2
2025.08.30 20:17:12 3: No I/O device found for FSensor_OG_BAD_N
2025.08.30 20:17:12 3: No I/O device found for FSensor_EG_BAD_N
2025.08.30 20:17:12 3: No I/O device found for Gartenhaus_Switch_2
2025.08.30 20:17:12 3: No I/O device found for Alarm_Sirene
2025.08.30 20:17:12 3: No I/O device found for Aussenlicht_vorn_Tuer
2025.08.30 20:17:12 3: No I/O device found for TSensor_GARAGENTOR
2025.08.30 20:17:12 3: No I/O device found for GB_Kreis_3
2025.08.30 20:17:12 3: No I/O device found for BM_EG_Flur
2025.08.30 20:17:12 3: No I/O device found for Gartenhaus_Garagentor
2025.08.30 20:17:12 3: No I/O device found for BM_Garage_Status_1
2025.08.30 20:17:12 3: No I/O device found for GB_Kreis_4
2025.08.30 20:17:12 3: No I/O device found for BM_Garage_Lux
2025.08.30 20:17:12 3: No I/O device found for BM_OG_Flur02
2025.08.30 20:17:12 3: No I/O device found for TSensor_GARAGE
2025.08.30 20:17:12 3: No I/O device found for FSensor_OG_KZ_N
2025.08.30 20:17:12 3: No I/O device found for Innenlicht_FenstrStDo
2025.08.30 20:17:12 3: No I/O device found for TSensor_GARAGE_HWR
2025.08.30 20:17:12 3: No I/O device found for FSensor_EG_WZ_2_W
2025.08.30 20:17:12 3: No I/O device found for FSensor_EG_BUERO_S
2025.08.30 20:17:12 3: No I/O device found for BM_Garage_Status_2
2025.08.30 20:17:12 3: No I/O device found for FSensor_EG_WZ_1_W
2025.08.30 20:17:12 3: No I/O device found for Gartenhaus_Master_Switch
2025.08.30 20:17:12 3: No I/O device found for GB_Kreis_1
2025.08.30 20:17:12 3: No I/O device found for BM_EG_Flur02
2025.08.30 20:17:12 3: No I/O device found for BM_Garage
2025.08.30 20:17:12 3: No I/O device found for Gartenhaus_Steckdosen
2025.08.30 20:17:12 3: No I/O device found for FSensor_OG_SZ_1_S
2025.08.30 20:17:12 3: No I/O device found for Alarm_Wassersensor
2025.08.30 20:17:12 3: No I/O device found for Aussenlicht_Modul_1
2025.08.30 20:17:12 3: No I/O device found for FIBARO_RGB_1_last_State
2025.08.30 20:17:12 3: No I/O device found for Innenlicht_Treppe
2025.08.30 20:17:12 3: No I/O device found for BM_EG_Flur01
2025.08.30 20:17:12 3: No I/O device found for FSensor_EG_WZ_K_S
2025.08.30 20:17:12 3: No I/O device found for BM_OG_Flur
2025.08.30 20:17:12 3: No I/O device found for Aussenlicht_vorn_Garage
2025.08.30 20:17:12 3: No I/O device found for FSensor_OG_SZ_2_S
2025.08.30 20:17:12 3: No I/O device found for WallPlug_Kuehlschrank
2025.08.30 20:17:12 3: No I/O device found for FIBARO_RGB_1
2025.08.30 20:17:12 3: No I/O device found for Innenlicht_Modul_1
2025.08.30 20:17:12 1: Messages collected while initializing FHEM:SecurityCheck:
  WEBtablet is not password protected
  MyBroker is not password protected
  WEB is not password protected
  WEBapi is not password protected
  telnetPort is not password protected
  tPortLocal is not password protected
  WEBweather is not password protected

Protect this FHEM installation by configuring the allowed device allowed_WEBphone
You can disable this message with attr global motd none

2025.08.30 20:17:12 3: ESPEasy ESPEasy_BRIDGE: Bridge v2.18 port [TCP:IPV4:8383] opened.
2025.08.30 20:17:13 3: Opening HWR_KLIMAANLAGE device 192.168.178.108:502
2025.08.30 20:17:13 3: Opening HWR_WAERMEPUMPE device 192.168.178.108:502
2025.08.30 20:17:13 3: Opening Mosquitto device 127.0.0.1:1883
2025.08.30 20:17:13 3: Mosquitto device opened
2025.08.30 20:17:13 3: deCONZ: websocket opened to 192.168.178.100:8091
2025.08.30 20:17:13 2: deCONZ: autocreate: created 0/0/0 devices (ignored 0/0/0)
2025.08.30 20:17:13 1: usb create starting
2025.08.30 20:17:13 3: Probing ZWDongle device /dev/serial0
2025.08.30 20:17:13 1: ZWDongle: Can't open /dev/serial0: Device or resource busy
2025.08.30 20:17:13 3: Probing CUL device /dev/ttyAMA0
2025.08.30 20:17:13 1: CUL: Can't open /dev/ttyAMA0: Device or resource busy
2025.08.30 20:17:13 3: Probing TCM_ESP3 device /dev/ttyUSB0
2025.08.30 20:17:13 3: Probing TCM_ESP2 device /dev/ttyUSB0
2025.08.30 20:17:13 3: Probing FHZ device /dev/ttyUSB0
2025.08.30 20:17:13 3: Probing TRX device /dev/ttyUSB0
2025.08.30 20:17:14 3: Probing ZWDongle device /dev/ttyUSB0
2025.08.30 20:17:14 3: Probing SIGNALDuino device /dev/ttyUSB0
2025.08.30 20:17:14 3: Probing MYSENSORS device /dev/ttyUSB0
2025.08.30 20:17:15 3: Probing ArduCounter device /dev/ttyUSB0
2025.08.30 20:17:15 3: Probing ElsnerWS device /dev/ttyUSB0



Ich hoffe wir kommen der Sache noch auf die Spur?! Das wäre echt genial... ich will den Stick nicht in die Tonne hauen.

VG und schönes WE noch...
René


PS: Bzgl des kuriosen Nebeneffektes: Wenn ich sowohl HA mit 10pro und FHEM mit 5Gen laufen lassen, egal wo ich schalte, beide Instanzen bekommen die Änderung mit... Also wenn ich in FHEM eine Lampe schalte, dann ändert sich auch der Status des Schalters in HA und umgekehrt. Also beide Instanzen können schalten und kriegen auch die Rückmeldungen.
#60
FHEM Code changes / Revision 30232: 76_SolarForeca...
Letzter Beitrag von System - 30 August 2025, 20:50:28
Revision 30232: 76_SolarForecast: contrib V1.58.0

76_SolarForecast: contrib V1.58.0

Source: Revision 30232: 76_SolarForecast: contrib V1.58.0
Seiten 1 ... 4 5 6 7 8 ... 10