Neueste Beiträge

[list d_rpc017191BidCos_RF]

#11

Homematic / Aw: keine Readings von OpenCCU

Letzter Beitrag von Burny4600 - 01 Februar 2026, 17:47:52

Warum gibt es hier zwei verschiedene IP-Adressen?

Die eine IP-Adresse ist der FHEM-Pi, die andere der OpenCCU-Pi.

list d_rpc017191BidCos_RF

Code Auswählen Erweitern

Internals:
   CCUNum     1
   DEF        http://192.168.17.191 BidCos-RF
   FD         249
   FUUID      697a1c4f-f33f-f4d2-7313-892fb70606b883ac
   IODev      OpenCCU
   NAME       d_rpc017191BidCos_RF
   NR         9581
   RPCPID     29398
   RPCState   running
   STATE      running/OK
   TYPE       HMCCURPCPROC
   callback   192.168.17.191:4012
   ccuip      192.168.17.191
   ccustate   timeout
   ccutype    CCU2/3
   eventCount 319
   host       192.168.17.191
   prot       http
   rpcid      017181017191
   rpcinterface BidCos-RF
   rpcip      192.168.17.191
   rpcport    2001
   version    2024-12
   READINGS:
     2026-02-01 16:48:26   rpcstate        running
     2026-02-01 16:48:26   state           OK
   hmccu:
     defaultaddr 192.168.17.181
     devspec    BidCos-RF
     evtime     0
     localaddr  192.168.17.191
     rpcstarttime 1769960906.26017
     rpc:
       auth       
       avgdelay   70.6992204500611
       cbport     4012
       cburl      http://192.168.17.191:4012/fh2001
       clkey      CB2001017181017191
       clurl     
       evtime     1769964500.45024
       methods    abortDeleteDevice,activateLinkParamset,addDevice,addLink,addVirtualDeviceInstance,changeKey,clearConfigCache,deleteDevice,deleteVolatileMetadata,determineParameter,exit,getAllMetadata,getDeviceDescription,getInstallMode,getKeyMismatchDevice,getLinkInfo,getLinkPeers,getLinks,getMetadata,getParamset,getParamsetDescription,getParamsetId,getServiceMessages,getValue,getVersion,getVolatileMetadata,hasVolatileMetadata,init,listBidcosInterfaces,listDevices,listReplaceableDevices,listTeams,logLevel,ping,putParamset,refreshDeployedDeviceFirmwareList,removeLink,replaceDevice,reportValueUsage,restoreConfigToDevice,rssiInfo,setBidcosInterface,setInstallMode,setInterfaceClock,setLinkInfo,setMetadata,setRFLGWInfoLED,setTeam,setTempKey,setValue,setVolatileMetadata,system.listMethods,system.methodHelp,updateFirmware,system.multicall
       multicall  system.multicall
       pid        29398
       port       2001
       state      running
       sumdelay   0
       rec:
         DD         0
         EV         0
         EX         0
         IN         0
         ND         0
         RA         0
         RD         0
         SL         1
         ST         5
         TO         6
         UD         0
       snd:
         DD         0
         EV         0
         EX         0
         IN         0
         ND         0
         RA         0
         RD         0
         SL         0
         TO         0
         UD         0
Attributes:
   alias      OpenCCU RPC BidCos-RF
   devStateStyle style="text-align:left;;font-weight:bold;;"
   eventMap   /rpcserver on:on/rpcserver off:off/
   group      .HomeMatic CCUs
   icon       hm_ccu
   room       _HM,_RxTx
   rpcServerAddr 192.168.17.191
   rpcServerPort 2001
   sortby     02.02
   stateFormat rpcstate/state
   verbose    2

#12

Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...

Letzter Beitrag von flashworker - 01 Februar 2026, 17:35:04

Hallo zusammen, vor allem an die Shelly-Entwickler...

Es wäre schön, wenn ihr das Reading "restart_required" mit aufnehmen könntet.

Oder mir ein Tipp geben, wie ich folgenden Zeile
CodeAuswählen

Code Auswählen Erweitern

readingsBulkUpdateIfChanged($hash,"restart_required",($jhash->{sys}{restart_required}==1)?"true":"false");in ein userReading umschreiben kann.

Vielen Dank für das Shelly-Modul und eure Mühe

Grüße
Ralf

#13

Homematic / Aw: keine Readings von OpenCCU

Letzter Beitrag von Ralli - 01 Februar 2026, 17:31:43

Code Auswählen Erweitern

2026.02.01 16:48:16.074 2: HMCCURPCPROC [d_rpc017191HmIP_RF] Registering callback http://192.168.17.191:4030/fh2010 of type A with ID CB2010017181017191 at http://192.168.17.191:2010
2026.02.01 16:48:16.132 2: HMCCURPCPROC [d_rpc017191VirtualDevices] Registering callback http://192.168.17.181:14702/fh9292 of type A with ID CB9292017181017191 at http://192.168.17.191:9292/groups

Warum gibt es hier zwei verschiedene IP-Adressen?

[get Gerät values]

#14

Homematic / keine Readings von OpenCCU

Letzter Beitrag von Burny4600 - 01 Februar 2026, 16:25:09

Ich habe die neuen Geräte von der OpenCCU nach FHEM importiert.
Die Steuerung mittels FHEM über die OpenCCU funktioniert. Nur ich bekomme keine Readings von den Geräten geliefert.

Führe ich ein get Gerät values am Gerät aus, bekomme ich die Readings geliefert.
Sind für die automatischen Readings separate Konfiguration notwendig?

FHEM LOG

Code Auswählen Erweitern

2026.02.01 16:46:30.017 2: HMCCURPCPROC [d_rpc017191BidCos_RF] Please restart RPC server to apply attribute changes
2026.02.01 16:47:37.619 2: HMCCURPCPROC [d_rpc017191HmIP_RF] Please restart RPC server to apply attribute changes
2026.02.01 16:48:04.113 2: HMCCURPCPROC [d_rpc017191BidCos_RF] Received no events from interface CB2001017181017191 for 600.729223966599 seconds
2026.02.01 16:48:08.448 1: HMCCURPCPROC [d_rpc017191VirtualDevices] Stopping RPC server CB9292017181017191
2026.02.01 16:48:08.457 1: HMCCURPCPROC [d_rpc017191VirtualDevices] Deregistering RPC server http://192.168.xxx.xxx:14702/fh9292 with ID CB9292017181017191 at http://192.168.yyy.yyy:9292/groups
2026.02.01 16:48:08.482 1: HMCCURPCPROC [d_rpc017191VirtualDevices] Callback for RPC server CB9292017181017191 deregistered
2026.02.01 16:48:08.490 2: HMCCURPCPROC [d_rpc017191VirtualDevices] Sending signal INT to RPC server process CB9292017181017191 with PID=1173
2026.02.01 16:48:08.490 2: HMCCURPCPROC [d_rpc017191VirtualDevices] Scheduling cleanup in 30 seconds
2026.02.01 16:48:08.491 2: HMCCURPCPROC [d_rpc017191VirtualDevices] CB9292017181017191 received signal INT
2026.02.01 16:48:08.496 1: HMCCURPCPROC [d_rpc017191VirtualDevices] RPC server CB9292017181017191 stopped handling connections. PID=1173 run=0
2026.02.01 16:48:08.496 2: HMCCURPCPROC [d_rpc017191VirtualDevices] Number of I/O errors = 0
2026.02.01 16:48:09.491 1: HMCCURPCPROC [d_rpc017191BidCos_RF] Stopping RPC server CB2001017181017191
2026.02.01 16:48:09.497 1: HMCCURPCPROC [d_rpc017191BidCos_RF] Deregistering RPC server http://192.168.xxx.xxx:7411/fh2001 with ID CB2001017181017191 at http://192.168.yyy.yyy:2001
2026.02.01 16:48:09.509 1: HMCCURPCPROC [d_rpc017191BidCos_RF] Callback for RPC server CB2001017181017191 deregistered
2026.02.01 16:48:09.515 2: HMCCURPCPROC [d_rpc017191BidCos_RF] Sending signal INT to RPC server process CB2001017181017191 with PID=1174
2026.02.01 16:48:09.516 2: HMCCURPCPROC [d_rpc017191BidCos_RF] Scheduling cleanup in 30 seconds
2026.02.01 16:48:09.516 2: HMCCURPCPROC [d_rpc017191BidCos_RF] CB2001017181017191 received signal INT
2026.02.01 16:48:09.533 1: HMCCURPCPROC [d_rpc017191BidCos_RF] RPC server CB2001017181017191 stopped handling connections. PID=1174 run=0
2026.02.01 16:48:09.533 2: HMCCURPCPROC [d_rpc017191BidCos_RF] Number of I/O errors = 0
2026.02.01 16:48:10.516 1: HMCCURPCPROC [d_rpc017191HmIP_RF] Stopping RPC server CB2010017181017191
2026.02.01 16:48:10.525 1: HMCCURPCPROC [d_rpc017191HmIP_RF] Deregistering RPC server http://192.168.xxx.xxx:7420/fh2010 with ID CB2010017181017191 at http://192.168.yyy.yyy:2010
2026.02.01 16:48:10.548 1: HMCCURPCPROC [d_rpc017191HmIP_RF] Callback for RPC server CB2010017181017191 deregistered
2026.02.01 16:48:10.557 2: HMCCURPCPROC [d_rpc017191HmIP_RF] Sending signal INT to RPC server process CB2010017181017191 with PID=1175
2026.02.01 16:48:10.557 2: HMCCURPCPROC [d_rpc017191HmIP_RF] Scheduling cleanup in 30 seconds
2026.02.01 16:48:10.557 2: HMCCURPCPROC [d_rpc017191HmIP_RF] CB2010017181017191 received signal INT
2026.02.01 16:48:10.573 1: HMCCURPCPROC [d_rpc017191HmIP_RF] RPC server CB2010017181017191 stopped handling connections. PID=1175 run=0
2026.02.01 16:48:10.574 2: HMCCURPCPROC [d_rpc017191HmIP_RF] Number of I/O errors = 389
2026.02.01 16:48:11.958 1: HMCCURPCPROC [d_rpc017191HmIP_RF] RPC server process CB2010017181017191 terminated.
2026.02.01 16:48:11.966 2: HMCCURPCPROC [d_rpc017191HmIP_RF] Stop I/O handling
2026.02.01 16:48:11.983 2: HMCCURPCPROC [d_rpc017191HmIP_RF] RPC server stopped. Cancel delayed shutdown.
2026.02.01 16:48:12.614 1: HMCCURPCPROC [d_rpc017191VirtualDevices] RPC server process CB9292017181017191 terminated.
2026.02.01 16:48:12.614 2: HMCCURPCPROC [d_rpc017191VirtualDevices] Stop I/O handling
2026.02.01 16:48:12.631 2: HMCCURPCPROC [d_rpc017191VirtualDevices] RPC server stopped. Cancel delayed shutdown.
2026.02.01 16:48:12.903 1: HMCCURPCPROC [d_rpc017191BidCos_RF] RPC server process CB2001017181017191 terminated.
2026.02.01 16:48:12.911 1: HMCCU [OpenCCU] All RPC servers inactive
2026.02.01 16:48:12.926 2: HMCCURPCPROC [d_rpc017191BidCos_RF] Stop I/O handling
2026.02.01 16:48:12.944 2: HMCCURPCPROC [d_rpc017191BidCos_RF] RPC server stopped. Cancel delayed shutdown.
2026.02.01 16:48:15.867 2: HMCCU [OpenCCU] RPC device for interface VirtualDevices: d_rpc017191VirtualDevices
2026.02.01 16:48:15.867 2: HMCCU [OpenCCU] RPC device for interface HmIP-RF: d_rpc017191HmIP_RF
2026.02.01 16:48:15.867 2: HMCCU [OpenCCU] RPC device for interface BidCos-RF: d_rpc017191BidCos_RF
2026.02.01 16:48:15.878 2: HMCCURPCPROC [d_rpc017191VirtualDevices] RPC server process started for interface VirtualDevices with PID=29396
2026.02.01 16:48:15.907 2: HMCCURPCPROC [d_rpc017191VirtualDevices] Initializing RPC server CB9292017181017191 for interface VirtualDevices
2026.02.01 16:48:15.910 1: HMCCURPCPROC [d_rpc017191VirtualDevices] RPC server starting
2026.02.01 16:48:15.940 2: HMCCURPCPROC [d_rpc017191VirtualDevices] Callback server CB9292017181017191 created. Listening on port 14702
2026.02.01 16:48:15.942 2: HMCCURPCPROC [d_rpc017191VirtualDevices] CB9292017181017191 accepting connections. PID=29396
2026.02.01 16:48:15.942 2: HMCCURPCPROC [d_rpc017191HmIP_RF] RPC server process started for interface HmIP-RF with PID=29397
2026.02.01 16:48:15.971 2: HMCCURPCPROC [d_rpc017191HmIP_RF] Initializing RPC server CB2010017181017191 for interface HmIP-RF
2026.02.01 16:48:15.974 1: HMCCURPCPROC [d_rpc017191HmIP_RF] RPC server starting
2026.02.01 16:48:15.997 2: HMCCURPCPROC [d_rpc017191BidCos_RF] RPC server process started for interface BidCos-RF with PID=29398
2026.02.01 16:48:16.011 2: HMCCURPCPROC [d_rpc017191HmIP_RF] Callback server CB2010017181017191 created. Listening on port 4030
2026.02.01 16:48:16.013 2: HMCCURPCPROC [d_rpc017191HmIP_RF] CB2010017181017191 accepting connections. PID=29397
2026.02.01 16:48:16.028 2: HMCCURPCPROC [d_rpc017191BidCos_RF] Initializing RPC server CB2001017181017191 for interface BidCos-RF
2026.02.01 16:48:16.032 1: HMCCURPCPROC [d_rpc017191BidCos_RF] RPC server starting
2026.02.01 16:48:16.042 2: HMCCU [OpenCCU] RPC server start: 3 started, 0 already running, 0 failed to start
2026.02.01 16:48:16.062 2: HMCCURPCPROC [d_rpc017191BidCos_RF] Callback server CB2001017181017191 created. Listening on port 4012
2026.02.01 16:48:16.063 2: HMCCURPCPROC [d_rpc017191BidCos_RF] CB2001017181017191 accepting connections. PID=29398
2026.02.01 16:48:16.065 2: HMCCURPCPROC [d_rpc017191HmIP_RF] RPC server CB2010017181017191 enters server loop
2026.02.01 16:48:16.074 2: HMCCURPCPROC [d_rpc017191HmIP_RF] Registering callback http://192.168.yyy.yyy:4030/fh2010 of type A with ID CB2010017181017191 at http://192.168.YYY.YYY:2010
2026.02.01 16:48:16.103 1: HMCCURPCPROC [d_rpc017191HmIP_RF] RPC server CB2010017181017191 running
2026.02.01 16:48:16.131 2: HMCCURPCPROC [d_rpc017191VirtualDevices] RPC server CB9292017181017191 enters server loop
2026.02.01 16:48:16.132 2: HMCCURPCPROC [d_rpc017191VirtualDevices] Registering callback http://192.168.xxx.xxx:14702/fh9292 of type A with ID CB9292017181017191 at http://192.168.YYY.YYY:9292/groups
2026.02.01 16:48:26.161 1: HMCCURPCPROC [d_rpc017191VirtualDevices] RPC server CB9292017181017191 running
2026.02.01 16:48:26.207 2: HMCCURPCPROC [d_rpc017191BidCos_RF] RPC server CB2001017181017191 enters server loop
2026.02.01 16:48:26.208 2: HMCCURPCPROC [d_rpc017191BidCos_RF] Registering callback http://192.168.yyy.yyy:4012/fh2001 of type A with ID CB2001017181017191 at http://192.168.yyy.yyy:2001
2026.02.01 16:48:26.225 1: HMCCURPCPROC [d_rpc017191BidCos_RF] RPC server CB2001017181017191 running
2026.02.01 16:48:26.234 1: HMCCU [OpenCCU] All RPC servers running
2026.02.01 16:48:26.252 2: HMCCU [OpenCCU] Updating 12 of 12 devices matching devexp=.* filter=ccudevstate=active,ccuif=HmIP-RF|BidCos-RF|VirtualDevices nonBlocking
2026.02.01 16:48:26.252 2: HMCCU [OpenCCU] CCU device list 2b updated: EG_WI_WHZGO,OG1_WZ_RLO,OG1_BA_RLO,EG_SL_WHZGO,OG2_BU1_RLO,OG2_BU2_RLO,OG1_KI_RLO,OG1_KUE_RL2O,OG1_KUE_GSFO,OG1_KUE_RL1O,OG1_KUE_WAFO,AB_SGGO_BLO
2026.02.01 16:48:26.252 2: HMCCU [OpenCCU] FHEM device list 2b updated: EG_SL_WHZGO,OG1_KUE_RL1O,OG2_BU1_RLO,OG1_KUE_GSFO,OG2_BU2_RLO,AB_SGGO_BLO,OG1_KUE_RL2O,OG1_KI_RLO,OG1_BA_RLO,EG_WI_WHZGO,OG1_WZ_RLO,OG1_KUE_WAFO
2026.02.01 16:48:26.266 1: HMCCURPCPROC [d_rpc017191BidCos_RF] Scheduled CCU ping every 300 seconds
2026.02.01 16:48:31.540 2: HMCCU [OpenCCU] Error during CCU request. read from http://192.168.yyy.yyy:8181 timed out
2026.02.01 16:53:58.531 3: HMinfo HMinfo get:update :
2026.02.01 16:53:58.531 3: CUL_HM set ActionDetector update noArg
2026.02.01 16:58:16.788 2: HMCCURPCPROC [d_rpc017191BidCos_RF] Received no events from interface CB2001017181017191 for 600.724620103836 seconds
2026.02.01 17:00:34.195 3: CUL_HM set OG1_SL_KL_VEO off noArg
2026.02.01 17:00:34.372 3: CUL_HM set OG1_SL_BL_KAO off noArg
2026.02.01 17:00:57.922 3: nanoCUL433_OG1 IT: R_EG_WI ZU->off
2026.02.01 17:08:03.918 3: CUL_HM set OG1_SL_RLO off noArg
2026.02.01 17:08:17.559 2: HMCCURPCPROC [d_rpc017191BidCos_RF] Received no events from interface CB2001017181017191 for 600.697506189346 seconds
2026.02.01 17:08:22.050 3: CUL_HM set OG1_SL_RLO stop noArg
2026.02.01 17:08:38.799 3: CUL_HM HM_508831 attack::11FF8BDF508831020100
2026.02.01 17:08:38.894 3: CUL_HM HM_508831 attack::11FF8BDF508831020100
2026.02.01 17:08:38.942 3: CUL_HM HM_508831 attack::11FF8BDF508831020100
2026.02.01 17:08:58.635 3: HMinfo HMinfo get:update :
2026.02.01 17:08:58.636 3: CUL_HM set ActionDetector update noArg
2026.02.01 17:08:59.203 3: CUL_HM HM_508831 attack::11FF8BDF5088310301
2026.02.01 17:08:59.222 3: CUL_HM HM_508831 attack::11FF8BDF5088310301
2026.02.01 17:18:18.200 2: HMCCURPCPROC [d_rpc017191BidCos_RF] Received no events from interface CB2001017181017191 for 600.714983940125 seconds


#15

FHEMWEB / Aktualisierung von GUI-Element...

Letzter Beitrag von olwaldi - 01 Februar 2026, 14:47:17

Wieder in DENON_AVR aufgefallen ...

Wenn man in der WebGUI über den set-Button z.B. die Aktion volumeUp (kein zugehöriges Reading) ändert, um die Lautstärke (volumeStraight) um einen wählbaren Betrag zu erhöhen, wird der damit verbundene slider volumeStraight in webCmd nicht aktualisiert. Konkret wird zwar die Lautstärke um den gewählten Betrag vergrößert (auch das Reading volumeStraight wird aktualisiert), aber der Slider volumeStraight verharrt auf dem vorigen Wert. Wenn man nur im Web-Browser die WebGUI neu lädt, stimmt volumeStraight wieder. Noch merkwürdiger: In dem Moment, wenn man den set-Button drückt, wechselt das Auswahlmenü überraschenderweise auf volumeStraight mit richtigem Wert. Anbei ein Screenshot mit dem "Widerspruch" der gleichen zwei Slider.

Im Supportforum für DENON_AVR habe ich quasi dieselbe Frage auch gestellt, ist aber m.E. eher eine "Entwicklerfrage". Ich selber versuche gerade, in dem Modul den ein oder anderen Bug zu fixen.

Grüßle, Michael

#16

FHEMWEB / Unterschied :noArg zwischen Ge...

Letzter Beitrag von olwaldi - 01 Februar 2026, 14:24:00

Ist mir gerade im Modul DENON_AVR aufgefallen:

:noArg soll ja FHEMWEB ermöglichen, bei set- oder get-Befehlen in der GUI kein Eingabefeld vorzusehen. Funktioniert. Aber wenn dann (wie erwartet) die Usage-Meldung ausgegeben wird, wird bei get das Suffix :noArg mit ausgegeben, bei set hingegen erwartungsgemäß nicht. Ähnlich unerwartet wird bei get in der Usage-Meldung die Liste der Möglichkeiten mit ausgegeben

Das betrifft nicht nur DENON_AVR. Ähnlich verhält sich z.B. auch FRITZBOX bei

Code Auswählen Erweitern

get FritzBox unbekanntund liefert

Code Auswählen Erweitern

Unknown argument unbekannt, choose one of luaQuery luaData javaScript luaDectRingTone luaFunction luaInfo:lanDevices,ledSettings,vpnShares,wlanNeighborhood,mobileInfo,globalFilters,smartHomeDevices,smartHomeAutomation,kidProfiles,userInfos smartHomePreDef fritzLog lanDeviceInfo tr064Command tr064ServiceList:tr64,igd callApifromList:data.lua,query.lua,tr064,javascript showFritzOS:noArg


Grüßle, Michael

[vollständiges]

#17

Sonstige Systeme / Aw: Entwicklungs-Thread Modul ...

Letzter Beitrag von Starkstrombastler - 01 Februar 2026, 13:58:36

erscheint wieder die Meldung "Error: No Handler"

Dann bitte einmal ein vollständiges List  posten: mit der Funktion "Copy to forum" in die Zwischenablage ablegen und dann hier in Code-Tags einfügen.

Außerdem vorübergehend den Verbose-Level auf 5 erhöhen und einen on oder off Befehl absetzen. Den Auszug aus dem Log-File ebenfalls hier posten (auch in Code-Tags).

[8000]

#18

Multimedia / Aw: [Neues Modul] BOSE SoundTo...

Letzter Beitrag von Treibhaus - 01 Februar 2026, 13:44:39

Hallo,

das Git-Projekt :   verfolge ich auch erst einmal nicht weiter, da ich keine Kommunikation eines Tastenevents(der Box) am Server erkenne konnte.

Bei dem Soundfork hatte ich ebenfalls ein Webfindungsproblme auf port 8000.
(wahrscheinlich da "Docker-Portainer" diesen port 8000 für sich mitbeansprucht - dort aber eigentlich nix liefert)

Auch nach der Einrichtung der .env.private ..   wie bei Pah beschrieben. Allerdings auf port 8001 hat dies nicht geholfen.
(Diese liegt aber trotzdem noch im untersten Soundcork-Verzeichnis - keine Ahnung ob irgendein Programmschnipsel das noch einliest)


Gestartet wird nun mit:  fastapi run main.py --port=8001 --reload    Das funktioniert.

Code Auswählen Erweitern

(.venv) player_1one@RASPI-FHEM:/tmp/soundcork/soundcork $ fastapi run main.py --port=8001 --reload

   FastAPI   Starting production server 🚀

             Searching for package file structure from directories with __init__.py files
2026-02-01 13:24:33,870 [soundcork.datastore] INFO: Initiating Datastore
2026-02-01 13:24:33,873 [soundcork.datastore] INFO: Initiating Datastore
             Importing from /tmp/soundcork

    module   📁 soundcork
             ├── 🐍 __init__.py
             └── 🐍 main.py

      code   Importing the FastAPI app object from the module with the following code:

             from soundcork.main import app

       app   Using import string: soundcork.main:app

    server   Server started at http://0.0.0.0:8001
    server   Documentation at http://0.0.0.0:8001/docs

             Logs:

      INFO   Will watch for changes in these directories: ['/tmp/soundcork/soundcork']
2026-02-01 13:24:37,935 [uvicorn.error] INFO: Will watch for changes in these directories: ['/tmp/soundcork/soundcork']
      INFO   Uvicorn running on http://0.0.0.0:8001 (Press CTRL+C to quit)
2026-02-01 13:24:37,937 [uvicorn.error] INFO: Uvicorn running on http://0.0.0.0:8001 (Press CTRL+C to quit)
      INFO   Started reloader process [527947] using WatchFiles
2026-02-01 13:24:37,940 [uvicorn.error] INFO: Started reloader process [527947] using WatchFiles
2026-02-01 13:24:44,202 [soundcork.datastore] INFO: Initiating Datastore
2026-02-01 13:24:44,206 [soundcork.datastore] INFO: Initiating Datastore
      INFO   Started server process [527951]
2026-02-01 13:24:44,266 [uvicorn.error] INFO: Started server process [527951]
      INFO   Waiting for application startup.
2026-02-01 13:24:44,270 [uvicorn.error] INFO: Waiting for application startup.
2026-02-01 13:24:44,273 [soundcork.main] INFO: Starting up soundcork
2026-02-01 13:24:44,274 [soundcork.main] INFO: done starting up server
      INFO   Application startup complete.
2026-02-01 13:24:44,274 [uvicorn.error] INFO: Application startup complete.
      INFO   192.168.0.67:60848 - "POST /v1/scmudc/08DF1F1195D9 HTTP/1.1" 404
      INFO   192.168.0.67:60850 - "POST /v1/scmudc/08DF1F1195D9 HTTP/1.1" 404
     
^C

Leider aber auch nur soweit. Das der Post (aus einem Tastenevent an der Box den Pfad wohl nicht findet "404")    

Gruß Jörg

[sehr bewusst]

#19

Sonstiges / Aw: fhem-mcp - FHEM-Steuerungs...

Letzter Beitrag von Pati_Alpha - 01 Februar 2026, 12:44:02

Hey zusammen,

erstmal danke für das viele und teils sehr unterschiedliche Feedback - finde ich sehr spannend und freue mich, dass überhaupt etwas zurückkam!

Ein paar Punkte zur Einordnung, weil hier teilweise aneinander vorbeigeredet wird und zum generellen Kontext:
Der Ansatz war und ist von Anfang an als Experiment (bzw. sogar Spielerei) genannt, nicht als Vorschlag für eine produktive, dauerhafte Sprachsteuerung von FHEM. Mich interessiert daher weniger ,,wie schalte ich am effizientesten ein Licht", sondern ,,wie verhält sich ein LLM, wenn es strukturiert und kontrolliert auf ein bestehendes System zugreifen darf" bis eben hin zu "Wohin können wir das entwickeln, um z.B. für die geschickte Konfiguration ein stabiles, schnelles und genaues Tool zu bekommen".

Dass HomeAssistant in diese Richtung bereits deutlich weiter ist (MCP ist dort inzwischen etabliert) war dann noch zusätzliches Salz in der Wunde - der Softwarearchitekt und HA-Nutzer aus meinem (beruflichen) Projekt war z.B. sogar erstaunt, dass "wir" (FHEM) so etwas noch nicht haben! (Jaa, der Spott in der Kantine war groß... )
Ich bin mir aber auch nicht 100% sicher, was in HomeAssistant schon möglich ist. In meinem Falle habe ich ja zunächst sehr bewusst auf MCP-Tools, welche Geräte anlegen etc. verzichtet. Das wäre sicher aber einer der nächsten Schritte. Dachte da im nächsten Schritt des Experiments grob an ein Sandbox-FHEM in einer VM mit einigen Device-Dummys zu denen man dann mal Automatismen schreiben lässt oder so.

@kgie
Ja, genau das ist für mich einer der spannendsten nächsten Schritte!
Nicht Live-Steuerung, sondern Konfigurationserzeugung (Devices, DOIFs etc.).
Wichtig dabei: sicher grade am Anfang bzw. für Profi-Nutzer (unter welche ich die meisten Leute, die alleine im Forum schon nur nicht in ihre eigenen Threads schauen mal packen würde ) nicht

Code Auswählen Erweitern

,,Prompt => ungeprüfter Code => live", sondern eher

Code Auswählen Erweitern

Prompt => Vorschlag => Review => Anpassung/Refactoring => AktivierungGerade bei FHEM mit seiner offenen Doku, dem zugänglichen Code und der klaren Syntax sehe ich da Potenzial!

Zusätzlich würde ich mit RAG (Retrieval Augmented Generation) arbeiten, also Einbeziehen von Doku, Beispielen und ggf. Forenlösungen.

Dazu vielleicht noch ein Mini-Exkurs:
Viele schlechte Erfahrungen, welche Leute mit ,,Coding per KI" haben, kommen m.E. daher, dass ohne Spezifikation und Kontext gepromptet wird – dann sind inkonsistente Ergebnisse wenig überraschend und es wird abgeschmiert als "KI coded nicht in guter Qualität". Dass das an der Realität mittlerweile vorbei ist, sieht man aber natürlich an den Schlagzeilen wie z.B., dass Microsoft jetzt großflächig Claude Code für seine Entwickler ausrollt etc., wie man es also dreht, wendet oder ob man es selbst mag: Profis nutzen es, das ist klar! Man muss das "Werkzeug" aber natürlich gut verstehen und geschickt nutzen, da es ja nun doch etwas komplexer ist als z.B. ein Linter, der mich nur im JavaScript auf eine fehlende Klammer hinweist.
Anderes, realitätsnäheres Mini-Beispiel: Wenn ich 10-mal hintereinander selbst in ein gutes Tool wie Claude Code schlicht ,,Bau mir einen Taschenrechner" prompte, bekomme ich zwangsläufig 10 unterschiedliche Ergebnisse mit stark schwankender Qualität. Das ist kein Bug, sondern falsche Nutzung: fehlende Spezifikationen!
Hier hilft z.B. Spec-driven Development - also mit klaren Anforderungen reingehen:

• UI soll so aussehen
• Features müssen z.B. Wurzel und e-Funktion beinhalten
• Randbedingungen sind diese und jene
• Zielumgebung ist z.B. eine native Mac App in Swift
• etc.

und idealerweise ist das ganze RAG-unterstützt. So wird relevante Doku, bestehende Beispiele etc. vorab einbezogen und die Ergebnisse werden DEUTLICH konsistenter und nachvollziehbarer.
Genau diese Kombination halte ich für spannend, auch im FHEM-Kontext!


@pah
Ich glaube, hier sind wir fachlich näher beieinander, als es auf den ersten Blick bei der Antwort wirkt. Deine Punkte sind schlüssig - für eine produktive Sprachsteuerung, darum geht es hier aber nicht.
Ich denke, hier wurde "Experiment" und "Spielerei" völlig übergangen, aber das ist schon ok. Mit 1-2 Antworten in diese Richtung habe ich ja, wie anfangs erwähnt, auch gerechnet, daher ganz kurz zu den Punkten:

• Energieeffizienz ist bei einem Experiment und bei Entwicklung kein Bewertungskriterium. Das lokale System lief ohnehin, FHEM war nur ein angebundener Aktor etc.
• Intent-Erkennung per Babble / Regex etc. ist natürlich für strukturierte Sprache völlig ausreichend – das wird hier auch nicht ersetzt. Aber auch hier mal über "andere Nutzer" im Haus nachdenken, die vielleicht nicht wissen, wie ein Device genau heißt etc. - absoluter game changer, natürlich Sprache nutzen zu können, die nicht strukturiert ist und quasi keine Kenntnis über das System voraussetzt.
• Das gezeigte Normierungs-Beispiel ist korrekt, aber der experimentelle Unterschied ist: Das Modell entscheidet selbstständig über Devices, Fähigkeiten und Befehle. Um diese Entscheidungen kontrolliert ausführen zu können, braucht es dann genau so eine Schnittstelle wie MCP.
• Ein eigenes LLM nur für Hausautomatisierung ergibt keinen Sinn – das war auch nie die These. Davon ab geht das mMn generell in Richtung "KI Nutzen vs. Ressourcenverbrauch" und da könnten wir jetzt 700 Beispiele ausdiskutieren a la "Wenn du ChatGPT fragst, statt zu googeln verbrauchst du 10x mehr Energie für dasselbe Ergebnis", trotzdem tun Leute genau das nunmal, weil es natürlicher zu bedienen ist! Aber darum geht es hier wie gesagt nicht und das Thema möchte ich bitte entsprechend beenden.

@KölnSolar
Völlig berechtigter Hinweis! Das Thema hatte ich noch gar nicht erwähnt!
Bendenke aber hier auch mal den Unterschied bezüglich der Zugänglichkeit zwischen z.B.:

• komplexen, gewachsenen Profi-Setups mit hunderten Regeln
• Einsteiger- oder Hobby-Szenarien, wo jemand schlicht möchte, dass abends bei Bewegung drei Lampen angehen – und dafür erstmal eine Stunde braucht, nicht mit der Doku klar kommt, im Forum aber gesagt bekommt "Na lies doch die Doku" (scnr)

Grade letzterem Fall kann ,,KI als Vorschlagsgenerator" mMn helfen, solange klar ist, dass man Verantwortung und Verständnis nicht vollständig delegiert.

@RalfRog
Genau - wenn es einen MCP-Server für FHEM gibt, ist der Client im Prinzip austauschbar!
Lokales LLM, Cloud-LLM, Coding-Agent – alles denkbar, je nach Zielsetzung und Kostenmodell.
Hier fand ich eben lokale Modelle aus mehreren Gründen spannend, da man keine teuren Token bezahlt und ich sonst bei 8/10 Usern bereits das große "Jaja klar, dann weiß OpenAI demnächst auch noch, wo meine Lampe steht - NEIN, DANKE!" am Horizont gesehen habe. ... primär aber der experimentelle und spaßige Aspekt, sowas komplett selbst zu betreiben
Letztlich sind dann ja auch Lösungen denkbar wie ein LLM, was auf dem Haussteuerungsserver läuft und per Routing z.B. nur in komplexen Fällen bedient wird oder z.B. in einer VM für unterschiedliche Anwendungen im Haus zur Verfügung steht... die Möglichkeiten sind da unzählig - aber alle auch noch etwas weiter am Horizont.

Ich werde den Code aufräumen und dann gern teilen - Feedback aus unterschiedlichen Richtungen find ich aber weiterhin super spannend, gerade auch kritisch-konstruktives!
Hach, mir macht das Thema einfach Spaß.

Viele Grüße
Patrick

#20

Multimedia / Aw: [Neues Modul] BOSE SoundTo...

Letzter Beitrag von Prof. Dr. Peter Henning - 01 Februar 2026, 12:10:29

Der Server ,,startet" auch, ich muss aber das Environment .venv gesetzt lassen und auch in das Verzeichnis wechseln

Korrekt, das muss auch so sein.

Warum steht dort 0.0.0.0?

Ist bei mir auch so, scheint in Ordnung zu sein.

Naja auf die URL komme ich auch nicht

Ist nicht in Ordnung. Wenn man direkt die Url http://<IP>:8000 aufruft, MUSS als Response stehen

Code Auswählen Erweitern

Bose "Can't Brick Us"
Vermutung: Du hast vergessen, in der Datei .env.private die richtigen Daten einzutragen. Bei mir steht darin

Code Auswählen Erweitern

base_url = "http://192.168.0.94:8000"
data_dir = "/home/soundcork/db"
Nicht ganz trivial ist auch, was man in die Datei soundcork.service einträgt. Bei mir steht dort

Code Auswählen Erweitern

[Unit]
Description=Gunicorn Daemon for Soundcork
After=network.target

[Service]
User=soundcork
WorkingDirectory=/home/soundcork/soundcork/soundcork
ExecStart=/home/soundcork/soundcork/.venv/bin/gunicorn -c gunicorn_conf.py main:app


[Install]
WantedBy=multi-user.target

Konkret habe ich a.) den user soundcork hinzugefügt, mit Gruppe dialout. b.) In dessen home directory /home/soundcork das github-Projekt geklont, damit bin ich schon bei /home/soundcork/soundcork c.) Durch den Installationsprozess wird dann /home/soundcork/soundcork/soundcork erzeugt. Das ist reichlich wild, hoffentlich verbessert sich das noch im Lauf der Zeit.

Mit http://<IP>:8000/docs kommt man dann auf das API des soundcork Servers, und kann dort allerhand ausprobieren, siehe screenshot.

LG

pah