Hallo zusammen,
ich bin gerade dabei mein Fhem auf einem Raspberry Pi 4B in einen Docker Container umzuziehen. Zwar auf demselben Pi aber in einem neu aufgesetzten System (vorher Raspberry OS Buster, jetzt bookworm) und habe nun Probleme mit der Ansteuerung meiner Homematic-Devices (nicht IP) über einen CUL868 über TSCUL.
Dazu habe ich u.a. yaml über portainer als stack/composer eingefügt, das ich mir aus verschiedenen Infos zusammengebastelt habe.
Dann habe ich meinen alten /opt/fhem-Ordner in den Speicher des neuen Volumes gespielt und die datenbank ins neue mariadb kopiert.Es läuft nach einigen Problemen mit den Datenbankverbindungen und dem DBLogging soweit auch OK.
Der CUL funktioniert prinzipiell auch (State: initialized) und die Geräte reagieren auch (meist) prompt. Allerdings bekomme ich (bei allen Geräten) immer ein "MISSING ACK". "Meist" weil vermutlich durch die "CMDs pending..." keine weiteren Kommandos ausgeführt werden. Der Status wechselt dann auf "CMDs_done_Errors:1". Danach kann ich auch wieder schalten.
Ich habe auch mal versucht ein Gerät, die vccu und den CUL zu loggen (verbose=5), da steht aber nichts sinnvolles drin (s.u.).
Würde mich sehr über Hilfe bei der Fehlersuche freuen!
Danke!
Alex
Hier das yaml:
# This is an exmaple Docker Compose file to start your own Docker Stack
version: '2.3'
networks:
net:
driver: bridge
# enable_ipv6: true
ipam:
driver: default
config:
- subnet: 172.27.0.0/28
gateway: 172.27.0.1
# - subnet: fd00:0:0:0:27::/80
# gateway: fd00:0:0:0:27::1
services:
####
# HINT: use only ONE of the example "fhem:" service
# definitions below !
#
# Example to connect USB to the container w/o
# privileged mode (preferred method)
fhem:
image: fhem/fhem:latest
restart: always
#network_mode: host
networks:
net:
ipv4_address: 172.27.0.2
ports:
- "8083:8083"
volumes:
- "/var/lib/docker/volumes/fhem/fhem/:/opt/fhem/"
devices: # for privileged mode definde devices as volumes
- "/dev/CUL868:/dev/CUL868_0"
- "/dev/CUL433:/dev/CUL433_0"
environment:
FHEM_UID: 1000
FHEM_GID: 1000
TIMEOUT: 10
RESTART: 1
TELNETPORT: 7072
TZ: Europe/Berlin
CONFIGTYPE: configDB
#depends_on:
# - "mysql"
alexa-fhem:
depends_on:
- "fhem"
# condition: service_healthy
image: ghcr.io/fhem/alexa-fhem:latest
restart: always
#network_mode: host
networks:
net:
ipv4_address: 172.27.0.3
volumes:
- "/var/lib/docker/volumes/fhem/alexa-fhem/:/alexa-fhem/"
homebridge:
image: homebridge/homebridge:latest
restart: always
#network_mode: host
networks:
net:
ipv4_address: 172.27.0.4
ports:
- "8581:8581"
volumes:
- /var/lib/docker/volumes/fhem/homebridge:/homebridge
logging:
driver: json-file
options:
max-size: "10mb"
max-file: "1"
Hier die config meines CUL:
define CUL1 TSCUL /dev/CUL868_0@12000000 1234
attr CUL1 devStateIcon Initialized:general_ok
attr CUL1 group Zentrale
attr CUL1 hmId AA2170
attr CUL1 hmLanQlen 1_min
attr CUL1 icon cul_868
attr CUL1 model CUL
attr CUL1 rfmode HomeMatic
attr CUL1 room x_Geräte
attr CUL1 verbose 5
# CMDS ABCFGJKRUVWXYeiltx
# Clients STACKABLETS:STACKABLE:CUL_HM:CUL_IR:TSHMS
# DEF /dev/CUL868_0@12000000 1234
# DeviceName /dev/CUL868_0@12000000
# FD 9
# FHTID 1234
# FUUID 60a4214c-f33f-c40b-0e1a-510b13a0410c503c
# NAME CUL1
# NR 38
# PARTIAL
# RAWMSG
# STATE Initialized
# TYPE TSCUL
# VERSION VTS 0.38 CUL868
# VERSION_HW CUL_V3.4_0004
# VERSION_TS yes AES ChTblSize:209
# XmitOpen 1
# assignUpdCntI 117
# assignedIDsCnt 35
# eventCount 2
# initString XP0C
#X21
#Ar
#AM5
#AHAA2170
# msgLoadCurrent 0
# owner_CCU vccu
# MatchList:
# A:CUL_HM ^A....................
# B:CUL_IR ^I............
# C:TSHMS ^810e04......a001
# Y:STACKABLETS ^\*
# Z:STACKABLE ^\*
# READINGS:
# 2024-04-13 17:57:53 Xmit-Events non-HM:1 disconnected:1 ok:2
# 2024-04-13 17:56:41 cmds A B C F G J K R U V W X Y e i l t x
# 2024-04-13 17:57:53 cond ok
# 2024-04-13 17:56:41 prot_disconnected last
# 2024-04-13 17:56:42 prot_non-HM last
# 2024-04-13 17:57:53 prot_ok last
# 2024-04-13 17:56:43 state Initialized
# helper:
# CUrun 1
# ChkPart 0
# RA_Timeout 0
# SVTS 1
# VTS 1
# VTS_ACK 1
# VTS_AES 1
# assIdCnt 35
# assIdRep 35
# nRec 0
# recAlive 1
# recd 0
# DEVIOTS:
# RXfailTO
# HM:
# ChTblSize 209
# FUP 0
# HMactive 1
# hmCrdts 0
# hmSbusy 0
# ChTbl:
# 1487B900 01
# 150E0D00 01
# 185A9400 01
# 18AC5200 01
# 19397800 01
# 19399200 01
# 196A1100 01
# 196AC000 01
# 196CBA00 01
# 1994CB00 01
# 19963800 01
# 19DC0B00 01
# 1B09C700 01
# 23FB2500 01
# 27BEB300 01
# 27BECB00 01
# 284DFA00 01
# 294DE000 01
# 2C629700 01
# 4A9BF100 01
# 4B644000 01
# 4B9BDC00 01
# 4B9DE000 01
# 5AA7BF00 01
# 5AB2B600 01
# 5AB37400 01
# 5EA33C00 01
# 61122600 01
# 61122F00 01
# 620DAF00 01
# 65405100 01
# 6807BD00 01
# 6CB27600 01
# 6EDCE000 01
# 707D6100 01
# msgCNT:
# 0x02 15
# 0x03 507
# 0x09 169
# unknwn:
# cnd:
# 0 2
# 250 1
# 253 1
# hmLogHist:
# 09230992 A F103 15478196 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09231231 A F109 15478464 00 0B 17 A001 AA2170 199638 010E _sfail _noAnsw
# 323253 As 0B 17 A001 AA2170 199638 010E
# 09236172 A F103 15483376 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09236444 A F103 15483648 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09236719 A F103 15483920 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09236954 A F109 15484188 00 0B 17 A001 AA2170 199638 010E _sfail _noAnsw
# 328101 As 0B 17 A001 AA2170 199638 010E
# 09241021 A F103 15488224 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09241292 A F103 15488496 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09241564 A F103 15488768 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09241802 A F109 15489036 00 0B 17 A001 AA2170 199638 010E _sfail _noAnsw
# 09434793 A F002 15682028 00 01 CC _ping
# 10035095 A F002 16282348 00 01 CC _ping
# hmQ:
# 185A94:
# 18AC52:
# 1994CB:
# 199638:
# 284DFA:
# 294DE0:
# 4A9BF1:
# 4B6440:
# 4B9DE0:
# 620DAF:
# 654051:
# 6EDCE0:
# ids:
# 1487B9:
# cfg +1487B9,00,01,00
# name Garage_Tor_zuKontakt
# 150E0D:
# cfg +150E0D,00,01,00
# name bz_Fenster
# 185A94:
# cfg +185A94,00,01,00
# name HM_185A94
# 18AC52:
# cfg +18AC52,00,01,00
# name wg_Dimmer
# 193978:
# cfg +193978,02,01,00
# name bz_Klima
# 193992:
# cfg +193992,00,01,00
# name bz_Heizungsventil
# 196A11:
# cfg +196A11,00,01,00
# name sp_Fenster
# 196AC0:
# cfg +196AC0,02,01,00
# name sz_Fenster_links
# 196CBA:
# cfg +196CBA,00,01,00
# name ku_Fenster
# 1994CB:
# cfg +1994CB,00,01,00
# name ug_Drucker
# 199638:
# cfg +199638,00,01,00
# name wg_Vitrine
# 19DC0B:
# cfg +19DC0B,02,01,00
# name wz_Heizungsventil
# 1B09C7:
# cfg +1B09C7,00,01,00
# name aussen_Klima
# 23FB25:
# cfg +23FB25,00,01,00
# name Regensensor
# 27BEB3:
# cfg +27BEB3,00,01,00
# name wz_Bewegungsmelder
# 27BECB:
# cfg +27BECB,02,01,00
# name ug_Bewegungsmelder
# 284DFA:
# cfg +284DFA,00,01,00
# name wz_Aquarium
# 294DE0:
# cfg +294DE0,00,01,00
# name sz_Stern_gross
# 2C6297:
# cfg +2C6297,00,01,00
# name wz_Standleuchte_master
# 4A9BF1:
# cfg +4A9BF1,00,01,00
# name sz_Stern_klein
# 4B6440:
# cfg +4B6440,00,01,00
# name Rauchmelder_kz
# 4B9BDC:
# cfg +4B9BDC,00,01,00
# name Rauchmelder_Flur
# 4B9DE0:
# cfg +4B9DE0,00,01,00
# name Rauchmelder_sz
# 5AA7BF:
# cfg +5AA7BF,00,01,00
# name Rauchmelder_wz
# 5AB2B6:
# cfg +5AB2B6,00,01,00
# name Rauchmelder_sp
# 5AB374:
# cfg +5AB374,00,01,00
# name Rauchmelder_Keller
# 5EA33C:
# cfg +5EA33C,02,01,00
# name wz_Klima
# 611226:
# cfg +611226,02,01,00
# name ku_Thermostat
# 61122F:
# cfg +61122F,02,01,00
# name sp_Thermostat
# 620DAF:
# cfg +620DAF,00,01,00
# name Garten_Schaltkasten
# 654051:
# cfg +654051,00,01,00
# name wz_Thermostat
# 6807BD:
# cfg +6807BD,00,01,00
# name Wettersensor
# 6CB276:
# cfg +6CB276,00,01,00
# name sz_Schalter
# 6EDCE0:
# cfg +6EDCE0,00,01,00
# name wg_Markise
# 707D61:
# cfg +707D61,02,01,00
# name sz_Schalter2
# loadLvl:
# bl 40
# q:
# ATrNo 0
# HMcndN 0
# InQueues 0
# RQLt 0
# XRpCnt 0
# XRpTm 1713023806.81313
# answerPend 0
# hmLanQlen 1
# apIDs:
# 185A94 0
# 18AC52 0
# 1994CB 0
# 199638 0
# 284DFA 0
# 294DE0 0
# 4A9BF1 0
# 4B6440 0
# 4B9DE0 0
# 620DAF 0
# 654051 0
# 6EDCE0 0
# ref:
# Sdly 0
# ioBR 3840
# ioBRn 100
# ioBRnC 0
# ioBRs 0
# lHMt 16282348
# lSys 412688279
# pTTu 16
# pndAs 0
# pndCUAp 1
# pndTuP 1
# pngFrc 1
# pngLm 70
# pngRef -100000000
# scErr 0
# scF 1
# scFN 1
# scHT 4294967295
# scST 1799423801.2762
#
setstate CUL1 2024-04-13 17:57:53 Xmit-Events non-HM:1 disconnected:1 ok:2
setstate CUL1 2024-04-13 17:56:41 cmds A B C F G J K R U V W X Y e i l t x
setstate CUL1 2024-04-13 17:57:53 cond ok
setstate CUL1 2024-04-13 17:56:41 prot_disconnected last
setstate CUL1 2024-04-13 17:56:42 prot_non-HM last
setstate CUL1 2024-04-13 17:57:53 prot_ok last
setstate CUL1 2024-04-13 17:56:43 state Initialized
Hier noch die vccu:
define vccu CUL_HM AA2170
attr vccu .mId FFF0
attr vccu IOList CUL1
attr vccu IOgrp vccu
attr vccu expert defReg,rawReg
attr vccu group Zentrale
attr vccu hmKey 01:124c2375507fcae5711d777a3babc3bf
attr vccu icon hm_ccu.svg
attr vccu model CCU-FHEM
attr vccu room x_Geräte
attr vccu subType virtual
attr vccu verbose 5
attr vccu webCmd virtual:update:hmPairForSec 60
# DEF AA2170
# FUUID 60a42153-f33f-c40b-ecee-eea2b9dff4d6ab1e
# IODev CUL1
# NAME vccu
# NR 71
# NTFY_ORDER 48-vccu
# STATE CUL1:ok
# TYPE CUL_HM
# assignedIOs CUL1
# chanNo 01
# disableNotifyFn 1
# eventCount 4
# READINGS:
# 2024-04-13 17:56:45 IODev CUL1
# 2024-04-13 17:57:53 IOopen 1
# 2024-04-13 17:57:53 state CUL1:ok
# helper:
# HM_CMDNR 98
# peerFriend
# peerOpt v:virtual
# regLst
# rxType 1
# cmds:
# TmplKey :no:1713023807.15349
# TmplTs 1713023807.15349
# cmdKey 1:1:1::vccu::01:
# cmdLst:
# assignIO -IO- [({set}|unset)]
# clear [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
# defIgnUnknown noArg
# hmPairForSec [-sec-]
# hmPairSerial -serial-
# peerChan -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
# postEvent -condition-
# press [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
# pressL [(-peer-|{all})]
# pressS [(-peer-|{all})]
# tplSet_0 -tplChan-
# update noArg
# virtual [(1..50;1|{1})]
# lst:
# condition slider,0,1,255
# peer
# peerOpt
# tplChan
# tplDel
# tplPeer
# rtrvLst:
# cmdList [({short}|long)]
# deviceInfo [({short}|long)]
# list [({normal}|full)]
# listDevice noArg
# param -param-
# expert:
# def 1
# det 0
# raw 1
# tpl 0
# io:
# vccu vccu
# ioList:
# CUL1
# prefIO:
# mRssi:
# mNo
# io:
# CUL1:
# peerIDsH:
# prt:
# bErr 0
# sProc 0
# q:
# qReqConf
# qReqStat
# role:
# chn 1
# dev 1
# vrt 1
# tmpl:
#
setstate vccu CUL1:ok
setstate vccu 2024-04-13 17:56:45 IODev CUL1
setstate vccu 2024-04-13 17:57:53 IOopen 1
setstate vccu 2024-04-13 17:57:53 state CUL1:ok
Und hier ein Bsp-Gerät, das nicht geht:
define wg_Vitrine CUL_HM 199638
attr wg_Vitrine userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr wg_Vitrine .mId 0011
attr wg_Vitrine IOgrp vccu
attr wg_Vitrine alexaName Vitrine
attr wg_Vitrine alexaRoom Wohnzimmer
attr wg_Vitrine autoReadReg 4_reqStatus
attr wg_Vitrine expert defReg
attr wg_Vitrine firmware 1.9
attr wg_Vitrine fm_fav 6
attr wg_Vitrine fm_type socket,offbutton,onbutton
attr wg_Vitrine genericDeviceType light
attr wg_Vitrine group Licht
attr wg_Vitrine model HM-LC-SW1-PL
attr wg_Vitrine peerIDs 00000000
attr wg_Vitrine room EG_Wohnzimmer,Favourites,GoogleAssistant,Homekit,alexa,x_Licht
attr wg_Vitrine serialNr JEQ0055717
attr wg_Vitrine siriName Vitrine
attr wg_Vitrine subType switch
attr wg_Vitrine webCmd statusRequest:toggle:on:off
# DEF 199638
# FUUID 60a4214f-f33f-c40b-24c0-c92f7686d200281d
# IODev CUL1
# NAME wg_Vitrine
# NR 49
# NTFY_ORDER 48-wg_Vitrine
# STATE unreachable
# TYPE CUL_HM
# chanNo 01
# disableNotifyFn 1
# eventCount 44
# protCmdDel 7
# protCmdPend 1 CMDs_pending
# protResnd 18 last_at:2024-04-13 19:57:38
# protResndFail 6 last_at:2024-04-13 19:57:44
# protSnd 6 last_at:2024-04-13 19:57:27
# protState CMDs_pending
# READINGS:
# 2024-01-25 18:46:23 CommandAccepted yes
# 2018-08-27 04:26:43 D-firmware 1.9
# 2018-08-27 04:26:43 D-serialNr JEQ0055717
# 2024-04-13 19:59:39 IODev CUL1
# 2021-05-27 14:30:44 PairedTo 0xAA2170
# 2018-05-06 13:53:08 R-pairCentral 0xAA2170
# 2018-05-06 13:53:10 R-sign off
# 2021-05-27 14:31:45 cfgState ok
# 2024-04-13 19:59:39 commState CMDs_pending
# 2024-04-13 09:54:59 deviceMsg off (to vccu)
# 2024-04-13 09:54:59 level 0
# 2024-04-13 09:54:59 pct 0
# 2024-04-13 09:54:59 recentStateType info
# 2024-04-13 19:59:59 state unreachable
# 2024-04-13 09:54:59 timedOn off
# 2024-04-13 19:57:27 trigLast fhem:02
# cmdStack:
# ++A001AA2170199638010E
# helper:
# HM_CMDNR 24
# cSnd 01AA2170199638010E,11AA21701996380201C80000
# dlvl C8
# dlvlCmd ++A011AA21701996380201C80000
# mId 0002
# peerFriend peerSens,peerVirt
# peerIDsState complete
# peerOpt 3:switch
# regLst 0,1,3p
# rxType 1
# cmds:
# TmplKey :no:1713023807.21995
# TmplTs 1713023807.21995
# cmdKey 1:1:0::wg_Vitrine:0002:01:
# cmdLst:
# assignHmKey noArg
# clear [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
# deviceRename -newName-
# fwUpdate -filename- [-bootTime-]
# getConfig noArg
# getDevInfo noArg
# getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
# getVersion noArg
# inhibit [(on|{off})]
# off noArg
# on noArg
# on-for-timer -ontime-
# on-till -time-
# pair noArg
# peerBulk -peer1,peer2,...- [({set}|unset)]
# peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
# peerSmart -peerOpt-
# press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
# raw -data- [...]
# regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
# regSet [(prep|{exec})] -regName- -value- [-peerChn-]
# reset noArg
# sign [(on|{off})]
# statusRequest noArg
# toggle noArg
# tplDel -tplDel-
# tplSet_0 -tplChan-
# unpair noArg
# lst:
# condition slider,0,1,255
# peer
# peerOpt Garage_Tor_zuKontakt,Rauchmelder_TeamLead,Regensensor_Rain,Wettersensor,bz_Fenster,ku_Fenster,sp_Fenster,sz_Fenster_links,sz_Schalter2_Btn_01,sz_Schalter2_Btn_02,sz_Schalter_01,sz_Schalter_02,ug_Bewegungsmelder,vccu
# tplChan
# tplDel
# tplPeer
# rtrvLst:
# cmdList [({short}|long)]
# deviceInfo [({short}|long)]
# list [({normal}|full)]
# param -param-
# reg -addr- -list- [-peerChn-]
# regList noArg
# regTable noArg
# regVal -addr- -list- [-peerChn-]
# saveConfig [-filename-]
# tplInfo noArg
# expert:
# def 1
# det 0
# raw 0
# tpl 0
# io:
# flgs 0
# newChn +199638,00,01,00
# nextSend
# restoredIO CUL1
# rxt 0
# vccu vccu
# lRcTm:
# p:
# 199638
# 00
# 01
# 00
# prefIO:
# mRssi:
# mNo
# io:
# CUL1:
# 100
# 100
# peerIDsH:
# 00000000 broadcast
# prt:
# bErr 0
# sProc 2
# q:
# qReqConf
# qReqStat
# role:
# chn 1
# dev 1
# prs 1
# tmpl:
#
setstate wg_Vitrine unreachable
setstate wg_Vitrine 2018-08-27 04:26:43 .D-devInfo 010100
setstate wg_Vitrine 2018-08-27 04:26:43 .D-stc 10
setstate wg_Vitrine 2018-05-06 13:53:08 .R-intKeyVisib invisib
setstate wg_Vitrine 2021-05-27 14:30:44 .RegL_00. 00:00 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:AA 0B:21 0C:70
setstate wg_Vitrine 2021-05-27 14:30:44 .RegL_01. 00:00 08:00
setstate wg_Vitrine 2024-04-13 17:56:47 .associatedWith wg_Vitrine,wg_Vitrine
setstate wg_Vitrine 2021-05-27 14:30:45 .peerListRDate 2021-05-27 14:30:45
setstate wg_Vitrine 2024-04-13 09:54:59 .protLastRcv 20240413095459
setstate wg_Vitrine 2024-01-25 18:46:23 CommandAccepted yes
setstate wg_Vitrine 2018-08-27 04:26:43 D-firmware 1.9
setstate wg_Vitrine 2018-08-27 04:26:43 D-serialNr JEQ0055717
setstate wg_Vitrine 2024-04-13 19:59:39 IODev CUL1
setstate wg_Vitrine 2021-05-27 14:30:44 PairedTo 0xAA2170
setstate wg_Vitrine 2018-05-06 13:53:08 R-pairCentral 0xAA2170
setstate wg_Vitrine 2018-05-06 13:53:10 R-sign off
setstate wg_Vitrine 2021-05-27 14:31:45 cfgState ok
setstate wg_Vitrine 2024-04-13 19:59:39 commState CMDs_pending
setstate wg_Vitrine 2024-04-13 09:54:59 deviceMsg off (to vccu)
setstate wg_Vitrine 2024-04-13 09:54:59 level 0
setstate wg_Vitrine 2024-04-13 09:54:59 pct 0
setstate wg_Vitrine 2024-04-13 09:54:59 recentStateType info
setstate wg_Vitrine 2024-04-13 19:59:59 state unreachable
setstate wg_Vitrine 2024-04-13 09:54:59 timedOn off
setstate wg_Vitrine 2024-04-13 19:57:27 trigLast fhem:02
Logs:
CUL:
2024-04-13_17:57:53 CUL1 cond: ok
2024-04-13_17:57:53 CUL1 Xmit-Events: non-HM:1 disconnected:1 ok:2
2024-04-13_17:57:53 CUL1 prot_ok: last
vcu:
024-04-13_17:57:53 vccu IOopen: 1
2024-04-13_17:57:53 vccu CUL1:ok
Konsolen-Log bei Senden:
2024.04.13 20:05:05 5: TSCUL_Read CUL1: /AF10300406E72010E1AA011AA2170199638020100000080
2024.04.13 20:05:05 4: TSCUL_Parse: CUL1 10643060 A F103 00113096 01 0E 1A A011 AA2170 199638 0201000000 _CCAdly:4
2024.04.13 20:05:05 5: TSCUL_Read CUL1: /AF10300406EB7010E1AA011AA2170199638020100000080
2024.04.13 20:05:05 4: TSCUL_Parse: CUL1 10643336 A F103 00113372 01 0E 1A A011 AA2170 199638 0201000000 _CCAdly:4
2024.04.13 20:05:06 5: TSCUL_Read CUL1: /AF10900406EFB000E1AA011AA2170199638020100000080
2024.04.13 20:05:06 3: LogHist CUL1: 10631914 A F103 00101952 02 0E 1A A011 AA2170 199638 0201000000 _CCAdly:8
2024.04.13 20:05:06 3: LogHist CUL1: 10632188 A F103 00102224 01 0E 1A A011 AA2170 199638 0201000000 _CCAdly:4
2024.04.13 20:05:06 3: LogHist CUL1: 10632464 A F103 00102500 01 0E 1A A011 AA2170 199638 0201000000 _CCAdly:4
2024.04.13 20:05:06 3: LogHist CUL1: 10632704 A F109 00102772 00 0E 1A A011 AA2170 199638 0201000000 _sfail _noAnsw
2024.04.13 20:05:06 3: LogHist CUL1: 10635396 A F102 00105456 00 01 CC _ping
2024.04.13 20:05:06 3: LogHist CUL1: 152027 As 0E 1A A011 AA2170 199638 0201000000
2024.04.13 20:05:06 3: LogHist CUL1: 10637812 A F103 00107848 01 0E 1A A011 AA2170 199638 0201000000 _CCAdly:4
2024.04.13 20:05:06 3: LogHist CUL1: 10638088 A F103 00108124 01 0E 1A A011 AA2170 199638 0201000000 _CCAdly:4
2024.04.13 20:05:06 3: LogHist CUL1: 10638364 A F103 00108400 01 0E 1A A011 AA2170 199638 0201000000 _CCAdly:4
2024.04.13 20:05:06 3: LogHist CUL1: 10638604 A F109 00108672 00 0E 1A A011 AA2170 199638 0201000000 _sfail _noAnsw
2024.04.13 20:05:06 3: LogHist CUL1: 157000 As 0E 1A A011 AA2170 199638 0201000000
2024.04.13 20:05:06 3: LogHist CUL1: 10642785 A F103 00112824 02 0E 1A A011 AA2170 199638 0201000000 _CCAdly:8
2024.04.13 20:05:06 3: LogHist CUL1: 10643060 A F103 00113096 01 0E 1A A011 AA2170 199638 0201000000 _CCAdly:4
2024.04.13 20:05:06 3: LogHist CUL1: 10643336 A F103 00113372 01 0E 1A A011 AA2170 199638 0201000000 _CCAdly:4
2024.04.13 20:05:06 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 199638/wg_Vitrine: 10643578 A F109 00113644 00 0E 1A A011 AA2170 199638 0201000000 _sfail _noAnsw
2024.04.13 20:05:07 4: TSCUL_XmitAwaitHMTo CUL1: timeout - 199638
2024.04.13 20:07:10 5: CUL_HM set vccu ?
2024.04.13 20:08:17 5: CUL_HM set vccu ?
2024.04.13 20:08:17 5: CUL_HM set vccu ?
2024.04.13 20:08:17 5: CUL_HM get vccu ?
Konsolen-Log bei "shutdown restart"
2024.04.13 20:14:05 5: CUL_HM set wg_Dimmer ?
2024.04.13 20:14:05 5: CUL_HM set wg_Dimmer ?
2024.04.13 20:14:05 5: CUL_HM wg_Dimmer protEvent:CMDs_pending pending:3
2024.04.13 20:14:05 5: TSCUL_Read CUL1: /
2024.04.13 20:14:07 4: TSCUL_XmitAwaitHMTo CUL1: timeout - 620DAF
2024.04.13 20:14:09 4: TSCUL_Write: CUL1 sending As0BDCA001AA2170620DAF010E
2024.04.13 20:14:09 4: TSCUL_send: CUL1 176550 As 0B DC A001 AA2170 620DAF 010E
2024.04.13 20:14:09 4: TSCUL_XmitDlyHM: CUL1 id:620DAF rtoms:2342
2024.04.13 20:14:09 5: TSCUL_Read CUL1: /
2024.04.13 20:14:09 5: TSCUL_Read CUL1: /
2024.04.13 20:14:09 5: TSCUL_Read CUL1: /
2024.04.13 20:14:09 5: TSCUL_Read CUL1: /
2024.04.13 20:14:09 5: TSCUL_Read CUL1: /
2024.04.13 20:14:11 4: TSCUL_XmitAwaitHMTo CUL1: timeout - 620DAF
2024.04.13 20:14:14 5: CUL_HM set vccu ?
2024.04.13 20:14:15 1: sduino: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2024.04.13 20:14:15 5: TSCUL_Read CUL1: /VTS 0.38 CUL868
2024.04.13 20:14:15 4: TSCUL_Parse: CUL1 VTS 0.38 CUL868
2024.04.13 20:14:15 1: /dev/CUL433_0 disconnected, waiting to reappear (sduino)
2024.04.13 20:14:15 1: sduino: DoInit, /dev/CUL433_0@57600
2024.04.13 20:14:15 1: /dev/CUL433_0 reappeared (sduino)
2024.04.13 20:14:17 5: TSCUL_Read CUL1: /VTS 0.38 CUL868
2024.04.13 20:14:17 4: TSCUL_Parse: CUL1 VTS 0.38 CUL868
2024.04.13 20:14:17 1: /dev/CUL433_0 disconnected, waiting to reappear (sduino)
2024.04.13 20:14:17 1: sduino: DoInit, /dev/CUL433_0@57600
2024.04.13 20:14:17 1: /dev/CUL433_0 reappeared (sduino)
2024.04.13 20:14:19 5: TSCUL_Read CUL1: /
Update:
Kann es sein, dass es an einer unzureichenden Stromversorgung des Raspberry liegt? Ich hab mal den SIGNALduino ausgesteckt und jetzt geht es.
da würde Dir vcgencmd get_throttled
Auskunft geben.
ich dachte: hw alles wie zuvor, nur die sw anders.
auffällig finde ich "_CCAdly" im log.
cca meldungen bei der normalen culfw bedeutet, dass nicht gesendet wird, weil bereits jemand sendet.
also:
vcgencmd get_throttled
ergibt:
throttled=0x0
habs mehrmals gemacht.
Leider funktioniert es nun nach einem Neustart des Containers wieder nicht mehr, obwohl ich nichts an der CUL/HM-config geändert habe. Den SIGNALduino hab ich auch ausgesteckt (wegen Strom, dachte ich ja).
Sehr merkwürdig.
UPDATE:
Ein kompletter Neustart des Raspberry hat nichts gebracht. Dann hab ich im laufenden Betrieb den CUL ab- und wieder angesteckt. Jetzt geht's wieder.
Evtl. Hardwarefehler?
UPDATE2:
Nach Anstecken des SIGNALduino gehts wieder nicht. Nach ein paar Versuchen CUL ab- und wieder anstecken geht's wieder.
Hallo Alex, hallo zusammen,
hoffentlich out of topic, oder vielleicht doch ein größeres Problem mit der aktuellen Homematic FHEM Implementierung?
Ich habe ohne Docker Umzüge etc. seit 13.04.2024 (exakt der erste Post von Alex) auch massive Verbindungs-Probleme mit meinen Homematic Geräten.
Homematic ActionDectector:
alive:39 dead:0 unkn:10 off:0
HMInfo:
Vor ein paar Stunden:
I_actTotal
alive:26,dead:10,unkn:13,off:0
Aktuell:
I_actTotal
alive:39,dead:0,unkn:10,off:0
D.h. Dead hat sich wieder etwas verbessert, aber immer noch 10 Unknown Geräte. Prptokollfehler;
ERR__protocol
CmdDel:30,IOerr:12,ResndFail:25
ACK MISSING / PENDING Fehler das Hauptproblem. Einige Geräte arbeiten, andere sehr langsam, manche überhaupt nicht mehr.
Viele Schalter lassen sich aktivieren, aber der Status kommt nicht oder sehr langsam an.
Direkte Peer Verbindungen mit Wandtastern funktionieren jedoch an den besagten Geräten einwandfrei, was Funkstörungen sehr unwahrscheinlich macht.
- Funkstörungen in Analyse
- Verdacht: HM relevante FHEM Modulanpassungen in den letzten Wochen? Auch im Homematic Bereich wird geschraubt.
- Hardware Fehler ist bereits ausgeschlossen, da ich ein neues HMLANGW mit neuester Firmware konfiguriert habe, das sich exakt gleich verhält.
Werde berichten, ob sich bei mir etwas genaueres herausfinden lässt, oder ob das Problem mit dem von Axel übereinstimmt. Bin für Tipps auch sehr dankbar...
Viele Grüße
Andreas
Hallo Andreas,
Zitat von: AndreasGaus am 16 April 2024, 13:01:50Auch im Homematic Bereich wird geschraubt.
Kann ich irgendwie nicht erkennen? Ich habe aktuell update gemacht.
10_CUL_HM.pm 26934 2022-12-31 16:24:33Z martinp876
98_HMinfo.pm 26935 2022-12-31 16:25:33Z martinp876
00_HMLAN.pm 25204 2021-11-09 05:41:42Z martinp876
98_HMtemplate.pm 24835 2021-08-08 16:00:50Z martinp876
00_HMUARTLGW.pm 25203 2021-11-08 09:18:29Z mgernoth
HMConfig.pm 25160 2021-10-30 17:38:52Z martinp876
hm.js 2008 2021-03-01 12:00:00Z frank
Gruß Otto
Hallo Otto,
vielen Dank für die schnelle Reaktion!
Ich habe am besagten 13.04.2024 ein Update mit "update all" gemacht. Mit einem Auge meine ich da auch HMCCU*.pm Dateien gesehen zu haben.
Da ich die Produktivumgebung auch in git verwalte, kann ich bestätigen, dass sich neuerdings ein paar Dinge geändert haben (von "zap"):
88_HMCCU.pm: hauptsächlich eine Verbesserung des automatischen Beziehens von Firmware direkt von eQ3 Server?
88_HMCCUCHN.pm: eine Ergänzung um Metadaten (HMCCUCHN_Get Erweiterung, scheint recht zentral zu sein, im Bereich der Homematic "update config")
88_HMCCUDEV.pm: HMCCUDEV_Get Erweiterung bzgl. der Metadatenerweiterung oben
88_HMCCURPCPROC.pm: HMCCURPCPROC_StartRPCServer Erweiterung um einen Callback
HMCCUConf.pm: Herausnahme eines BLIND_VIRTUAL_RECEIVERS in der Readings Behandlung von Homematic / Unklare Anpassung von Sonderbehandlungen von Virtual Devices / Homematic Script Anpassungen
Bin aber da viel zu weit weg, herauszufinden, ob es daran liegen könnte. Am gestrigen Tag wurde auch wieder ein Update in diesem Bereich nachgeschoben, das ich leider nicht separat in git habe.
Mein letztes git commit meiner Produktumgebung mit noch funktionierender FHEM Installation war bei mir nachweislich am 19.03.2024.
Ich habe kurz vor meinem heutigen Posting einige Änderungen in der fhem.cfg von Hand gemacht, letztlich wurden die aber wieder überschrieben und scheinen nicht relevant. Nach einem shutdown restart", da dies ja für die Übernahme vieler Konfigurationen inzwischen notwendig ist, dann das Wunder:
Nach und nach gingen die Homematic Geräte wieder aus dem Zombie (Dead / Unknown State) in einen Lebendstatus über, nachdem diese 3 Tage lang mehr oder weniger tot waren (nach einigen kompletten Reboots meines Raspberry Pi). Das ist umso erstaunlicher, da ich 3 Tage lang alles mögliche versucht habe, es einzugrenzen (Hardware Tausch HMLANGW, Funk reduziert durch Abschalten von Philips Hue, Gardena, EnOcean, FS20) - alles ohne Erfolg.
Für mich kommen nach wie vor zwei Dinge in Frage, die vom 13. - 16.04-2024 ca. 1/3 der Homematic Gerät ausfallen ließ:
- Funkstörungen (Gardena Smart Gateway wurde vor einer Woche in Betrieb genommen und kurz vor den auftretenden Problemen auch in FHEM eingebunden; 13. / 14. war zudem ein Traumwetter mit erhöhter Sonnenaktivität ;-)
- Verdacht: HM relevante FHEM Modulanpassungen in den letzten Wochen: es könnte sein, dass nach der gestrigen Aktualisierung mit "update all" und einem "shutdown restart" das Problem behoben wurde.
Für Alex wäre es evtl. einen Versuch wert, ein Update zu machen und neu zu starten und mit Geduld auf das Wiedereintrudeln der Lebensgeister der Homematic Geräte zu warten..?
Oder was meinst Du?
Herzliche Grüße aus dem Schwarzwald und toi toi toi, Alex!
Andreas
Hallo Alex,
Zitatattr CUL1 hmLanQlen 1_min
Kannst Du auch auf 3_normal stellen.
Ein
get CUL1 ccconf
würde noch etwas über die Einstellung des Tranceivers verraten.
# hmLogHist:
# 09230992 A F103 15478196 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09231231 A F109 15478464 00 0B 17 A001 AA2170 199638 010E _sfail _noAnsw
# 323253 As 0B 17 A001 AA2170 199638 010E
# 09236172 A F103 15483376 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09236444 A F103 15483648 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09236719 A F103 15483920 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09236954 A F109 15484188 00 0B 17 A001 AA2170 199638 010E _sfail _noAnsw
# 328101 As 0B 17 A001 AA2170 199638 010E
# 09241021 A F103 15488224 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09241292 A F103 15488496 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09241564 A F103 15488768 01 0B 17 A001 AA2170 199638 010E _CCAdly:4
# 09241802 A F109 15489036 00 0B 17 A001 AA2170 199638 010E _sfail _noAnsw
und
Zitatund die Geräte reagieren auch (meist) prompt.
Sagt, dass schlicht keine Antwort auf Deine Sendeversuche empfangen wird, obwohl die Geräte schalten, diese also Deine gesendeten Pakete empfangen.
Hat sich die Position/Ausrichtung gegenüber dem vorherigen besseren Stand geändert?
Hat sich die Umgebung geändert (funktechnisch verschlechtert)? Potentielle Störer hinzugekommen?
ZitatKann es sein, dass es an einer unzureichenden Stromversorgung des Raspberry liegt? Ich hab mal den SIGNALduino ausgesteckt und jetzt geht es
Potentieller Störer?
@Frank:
Zitatauffällig finde ich "_CCAdly" im log.
cca meldungen bei der normalen culfw bedeutet, dass nicht gesendet wird, weil bereits jemand sendet.
Nein, _CCAdly gibt nur an, wie lange es gedauert hat, was senden zu können. 4 ist normal.
HM CCA channel busy error to
Log Eintrag würde auf einen abgebrochenen Sendeversuch wegen Kanalbelegung hinweisen.
ZitatEin kompletter Neustart des Raspberry hat nichts gebracht. Dann hab ich im laufenden Betrieb den CUL ab- und wieder angesteckt. Jetzt geht's wieder.
Und anders positioniert als zuvor? Antenne anders gebogen?
RSSI Informationen von HMInfo zu allen Devices könnten auch noch Hinweise liefern.
CUL kannst Du nebst Modulen auch mal auf aktuelleren Stand bringen https://forum.fhem.de/index.php?msg=1297324 (https://forum.fhem.de/index.php?msg=1297324)
Gruß, Ansgar.
Zitat von: AndreasGaus am 16 April 2024, 20:34:38dass sich neuerdings ein paar Dinge geändert haben (von "zap"):
Aber hier im Thread ging es um CUL_HM nicht um HMCCU - das sind zwei völlig getrennte Welten - auch wenn sie beide am Ende Homematic Geräte bedienen.
Und wenn ich deinen Post richtig verstehe, hast Du auch CUL_HM.
Ich habe kein CUL_HM, sondern die HMLANGW, daher mit Axel nicht direkt vergleichbar.
Da gebe ich Dir recht, insbesondere, wenn die Änderungen strikt getrennt sind, bringt wohl das Nachforschen bzgl. Bugs im FHEM Homematic Bereich für Axel nicht viel.
Es sei denn, es wurden gemeinsame Homematic Bereiche angepasst.
In meinem Fall bin ich mir da aber gar nicht ganz so sicher, da gab es ja schon einige Änderungen...
zu dem was Andreas geschrieben hat:
in der Tat hatte ich beim Umzug zu docker ein update von fhem gemacht. Und das Problem tritt jetzt auch in der alten Umgebung auf. Könnte also irgendwie schon mit dem update zu tun haben.
Insgesamt läuft es derzeit. Bei Neustart läuft es aber dann wieder nicht und ich muss paar mal Neustarten und CUL abziehen und wieder anstecken. Irgendwann geht's dann wieder. Ohne jegliche Änderung an der config. Ich habe auch das Gefühl, dass es manchmal ne Weile braucht. Also quasi erst nicht geht, dann aber ohne Neustart etc. nach paar Minuten dann wieder geht.
@Ansgar:
Danke für Deine Hilfe und Anregungen!
Das ist das Ergebnis des "get CUL1 ccconf":
CUL1 ccconf => freq:868.300MHz freqOffs:0.000kHz bWidth:101kHz freqIF:152.34kHz rAmpl:33dB sens:8dB dRate:9.993kBit/s
agcPrio:1 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0
CCAmode:3 csRelThr:10dB csAbsThr:7dB
An der Umgebung hat sich nichts geändert. Raspi steht an selber Stelle. CUL ist wie immer mit einem USB-Kabel hinten am Highboard angeklebt. Antenne wie immer. Aber bei Störungen durch andere Geräte sollte ja auch zumindest das ein oder andere ACK ankommen. Aber so gar nichts...?!
Stromversorgung hab ich inzwischen überwacht. Da gibt's keine Probleme weder mit Signalduino noch ohne.
Update des CUL werde ich mal versuchen. Hab etwas Angst...
@alle:
Bei mir geht es um CUL_HM
Zitat von: AndreasGaus am 16 April 2024, 21:31:06Ich habe kein CUL_HM, sondern die HMLANGW, daher mit Axel nicht direkt vergleichbar.
HMLANGW ist ein IO für CUL_HM
Es gibt zwei Anbindungen Homematic an FHEM
Der Name CUL_HM basiert darauf, dass der erste IO für Homematic seiner Zeit ein cul war. Erst später kamen weitere IOs hinzu die durch die Module HMLAN, HMUARTLGW eingebunden werden.
@Andreas ich meine, Du hast: CUL_HM welches als IO ein HM-LGW-O-TW-W-EU Funk-LAN Gateway hat das über HMUARTLGW eingebunden ist. ;D
OK. Ich muss mich in aller Form entschuldigen. Das Problem saß wie immer vor dem Bildschirm...
Ich hatte beim Umzug die udev-Regeln falsch eingestellt so, dass /dev/CUL868 und /dev/CUL433 auf dasselbe Gerät, nämlich den CUL (/dev/ttyUSB0) gezeigt haben. Dadurch hat natürlich das sduino device in fhem immer versucht, auf den CUL868 zuzugreifen und den scheinbar gestört. Drauf gekommen bin ich nur dank des Frmware-Updates, weil in dem Beitrag von Ansgar steht, dass sich das Device ändern kann und da hab ich dann nachgeschaut.. Oh Mann. Jetzt geht's bisher auch nach Neustart zuverlässig.
Mir ist nur aufgefallen, dass mit der aktualisierten CUL-Firmware die Reaktion minimal langsamer scheint. Jedenfalls bleibt er jetzt kurz auf set_on bzw set_off.
Euch allen vielen Dank für Eure Mühe!!
ZitatDer Name CUL_HM basiert darauf, dass der erste IO für Homematic seiner Zeit ein cul war. Erst später kamen weitere IOs hinzu die durch die Module HMLAN, HMUARTLGW eingebunden werden.
@Andreas ich meine, Du hast: CUL_HM welches als IO ein HM-LGW-O-TW-W-EU Funk-LAN Gateway hat das über HMUARTLGW eingebunden ist. ;D
Aha, nun wird einiges klarer, ein historischer Name. CUL war für mich immer meine uralte "Antenne" via Huckepack am Raspberry Pi für 433 MHz / 868 MHz. Eine habe ich sogar für FS20 für alte Geräte auch noch in Betrieb, angebunden mit FHEM2FHEM. Bei Homematic bin ich aber vom uralten runden HMLAN zum HMLANGW umgestiegen, da dieses etwas weniger Sorgen macht:
Alt: https://wiki.fhem.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter
#define HMLAN1 HMLAN 192.168.178.abc:1000
Neu: HM-LGW-O-TW-W-EU Funk-LAN
define HMLANGW HMUARTLGW 192.168.178.xyz
Und das läuft nach Deinen Worten via dem Modul HMUARTLGW, richtig!
Der ActionDetector ist dennoch immer noch am Laufen:
define ActionDetector CUL_HM 000000
Hoffe das passt?
Toll, Axel, dass es bei Dir auch wieder läuft. Du hast auch eine Erklärung, bei mir suche ich immer noch nach einer plausiblen Erklärung für das viele Tage dauernde Fehlverhalten vieler Homematic Geräte. Wenn es die Software nicht war, sollte ich mir mal einen Spectrum Analyzer zulegen ;-)
Hallo Andreas,
Zitat von: AndreasGaus am 16 April 2024, 13:01:50da ich ein neues HMLANGW mit neuester Firmware konfiguriert habe, das sich exakt gleich verhält.
ich kann dazu nichts konkret sagen, aber soviel: beim HM-MOD-RPI-PCB, welches auch über HMUARTLGW angebunden wird, war die aktuelle Firmware für CUL_HM kontraproduktiv. Die funktionierte nur mit HMCCU.
Zitat von: AndreasGaus am 18 April 2024, 13:45:55Hoffe das passt?
Ich denke schon...
Bei Dir klingt es vielleicht doch nach Funkstörungen? Irgendein Gerät liegt in der Ecke und jammert wegen der Batterie? Stichwort Bubbling Idiot
Du könntest auch die Problemgeräte sniffen (steht im Wiki wie es geht) vielleicht hat dann Frank eine Idee
Ein Standardsatz: hast Du mal mit hminfo auf dein System geschaut? ;)
Hallo Otto,
ja, hminfo habe ich sofort eingebaut, um eine bessere Übersicht zu bekommen.
Auf Anregung von Dir habe ich mich auf die Suche nach einem "Babbling Idiot" gemacht.
Hier ist er:
Ein Bewegungssensor HM-SEN-MDIR-SM, der mir jahrelang sehr zuverlässige Dienste geleistet hat,
wollte in der Nacht zu besagtem 13.04.2024 nicht mehr:
2024-04-12_23:45:42 A0_Flur_Bewegungsmelder Activity: dead
2024-04-13_14:14:36 A0_Flur_Bewegungsmelder motion: off
2024-04-13_14:14:36 A0_Flur_Bewegungsmelder noMotion
2024-04-13_14:23:27 A0_Flur_Bewegungsmelder Activity: unknown
2024-04-13_14:33:31 A0_Flur_Bewegungsmelder Activity: dead
2024-04-13_15:11:28 A0_Flur_Bewegungsmelder battery: ok
Am Morgen des 13.04. hatte ich dies bemerkt und die Batterien getauscht und mich noch gewundert, dass die alten noch recht gut waren.
Dann bin ich aus dem Haus und habe auswärts via VPN bemerkt, dass nichts mehr ist wie es war und um 14:14 Uhr rebootet. Nach diesem Neustart ging einiges wieder besser, dann aber wieder dasselbe oft sporadische Verhalten im Homematic Bereich, dass Geräte kein ACK senden (und auch Philips Hue war leicht betroffen, aber das ist man dort ja auch gewohnt ;D).
Im Laufe des Tages kam es dann zum Versagen von immer mehr Homematic-Geräten, was ca. 3 Tage nicht behebbar war.
Nach einem erneuten Reboot des Raspberry Pi auf dem der Haupt-FHEM bei mir läuft, dann alles plötzlich wieder OK. ACK kamen wieder an.
Nur der Bewegungsmelder hat sich in der gestrigen Nacht dann gemeldet und zwar massiv alle paar Minuten MOTION erkannt, ohne dass sich auch nur eine Spinne bewegt hätte.
Ich habe die Platine des Bewegungsmelders geprüft und nachgelötet, insbesondere einen Elko und dort auch die etwas langen Beinchen gekürzt.
Nun läuft auch dieser Bewegungsmelder wieder einwandfrei und wird hoffentlich keinen Störfunk mehr verursachen. Ich besorge mir noch ein Messgerät, um dies in Zukunft besser eingrenzen zu können.
Herzlichen Dank Dir für Deine wertvollen Tipps und die motivierenden Hinweise!
Ein schönes Wochenende nach Leipzig aus dem Schwarzwald...
Viele Grüße
Andreas
mit einigen DVB-T sticks plus SDR software soll man solche dauersender lokalisieren können.