Hallo Zusammen,
ich habe im Raum CUL_HM mehrere Devices die ich nicht zuordnen kann. Habe ich mir diese evt. vom Nachbarn gefangen ? Was sind den threeStateSensor, powerMeter, remote, pushButton und switch für devices ?
thermostat kenne ich, ich habe mehrere HM-CC-RT-DN im Einsatz. Wie kann ich jetzt feststellen, ob ich evt. einen Zuordnungsfehler gemacht habe ? Nicht das ich mir eigene Devices lösche ?
Gruß
Micha
irgendwie scheint es neuerdings nicht mehr üblich zu sein, einfach mal ein list von den beteiligten Devices zu liefern...
Fang doch mal mit dem "threeStateSensor" an. Der hat ein "model" und ist ziemlich sicher ein Drehgriff-Sensor. Wenn du sowas nicht hast, würde ich mal schauen, wie alt die Readings sind, dann siehst du, ob es eine "Leiche" ist (=> Löschen) oder ein aktives Gerät vom Nachbarn (=> ignore).
Mit meiner letzten Fassung von CUL_HM (zu der sich Martin diesbezüglich bisher nicht geäußert hat, zu finden in den "November-patches"), sollten solche Fremd-Geräte übrigens auch nicht mehr angelegt werden, wenn eine VCCU definiert ist (bzw. nur dann, wenn man den pair-Modus aktiviert und dann der Nachbar zufällig das Knöpfchen drückt). Vielleicht magst du Werbung machen...
entschuldigung :-( ich hätte ja gerne ein list von allen geräten gesendet ;-)
hier mal das vom ersten:
HM_5CCF8F
das entscheidene ist dann 2021-11-16 16:46:16 Activity dead ?
oder kann ich irgendwie probieren ob das licht an / aus geht ;-)
gruß
micha
Internals:
DEF 5CCF8F
FUUID 5c5007b2-f33f-a44f-eb52-553fee7388b6461c
IODev hmusb
NAME HM_5CCF8F
NR 594
NTFY_ORDER 48-HM_5CCF8F
STATE CMDs_done_Errors:1
TYPE CUL_HM
channel_01 HM_5CCF8F_Sw
channel_02 HM_5CCF8F_Pwr
channel_03 HM_5CCF8F_SenPwr
channel_04 HM_5CCF8F_SenI
channel_05 HM_5CCF8F_SenU
channel_06 HM_5CCF8F_SenF
disableNotifyFn 1
protCmdDel 13
protIOerr 1 last_at:2021-11-16 17:57:13
protState CMDs_done_Errors:1
READINGS:
2021-11-16 16:46:16 Activity dead
2018-03-22 17:50:45 CommandAccepted yes
from archivexx D-firmware 1.6
from archivexx D-serialNr OEQ0768281
2021-11-16 17:56:13 IODev hmusb
2019-05-02 21:50:01 PairedTo 0x102310
2021-11-16 17:56:11 cfgState updating
2021-11-16 17:57:13 commState CMDs_done_Errors:1
2019-05-02 21:49:56 powerOn 2019-05-02 21:49:56
2018-03-22 17:49:45 recentStateType info
2021-11-16 16:10:20 sabotageAttackId_ErrIoId_102310 cnt:12
2020-07-07 11:01:35 sabotageAttack_ErrIoAttack cnt 3920
2021-11-16 16:10:20 sabotageAttack_ErrIoAttack_cnt 12
2021-11-16 17:57:14 state CMDs_done_Errors:1
helper:
HM_CMDNR 101
cfgStateUpdt 0
mId 00AC
peerFriend -
peerOpt -:powerMeter
regLst 0
rxType 1
tmplChg 0
cfgChk:
idPc01 fail
idRc01 RegL_00.
cmds:
TmplKey :no:1637076440.33643
TmplTs 1637076440.33643
cmdKey 0:1:0::HM_5CCF8F:00AC:00:
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-]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt
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 1
tpl 0
io:
flgs 0
newChn +5CCF8F,00,00,00
rxt 0
vccu
p:
5CCF8F
00
00
00
prefIO:
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
tmpl:
Attributes:
IODev hmusb
actCycle 000:10
actStatus dead
autoReadReg 4_reqStatus
expert defReg,rawReg
firmware 1.6
model HM-ES-PMSW1-PL
room CUL_HM
serialNr OEQ0768281
subType powerMeter
webCmd getConfig:clear msgEvents
Poste doch noch ein list von deinem CUL.
Oder prüfe selbst, ob die ID bei PairedTo dieselbe wie bei denem CUL ist attr hmid.
Wenn nicht, dann "gehört" das Ding wohl eher nicht dir...
...und schalten ginge dann auch nicht... 😉
Sollte man aber wissen, wenn man Homematic via CUL_HM betreibt...
Wenn du eine vccu hast/hättest, dann würden Fremdgeräte dort "gesammelt"...
Gruß, Joachim
Ich meinte hmusb.
Wollte es editieren aber irgendwie wurde mir das "verweigert"...
Gruß, Joachim
Zitat von: MadMax-FHEM am 16 November 2021, 18:17:01
Wenn du eine vccu hast/hättest, dann würden Fremdgeräte dort "gesammelt"...
...das gilt aber mit der svn-Verison nur solange, wie keiner "Knöppe drückt"...
Ja aber (historisch) es sollte so sein?
Also wurde zumindest (in der Vergangenheit) so "beworben"... ;)
Gruß, Joachim
Zitat von: Beta-User am 16 November 2021, 17:53:23
irgendwie scheint es neuerdings nicht mehr üblich zu sein, einfach mal ein list von den beteiligten Devices zu liefern...
Forum ist auch Hilfe zur Selbsthilfe. Ich fand die Nennung aller Checkpunkte ausreichend - wobei aus meiner Sicht gerade der Hinweis auf das Pairing den besten Hinweis liefert, ob es das eigene oder ein fremdes Gerät ist.
ZitatMit meiner letzten Fassung von CUL_HM ... in den "November-patches"... sollten solche Fremd-Geräte übrigens auch nicht mehr angelegt werden, wenn eine VCCU definiert ist (bzw. nur dann, wenn man den pair-Modus aktiviert und dann der Nachbar zufällig das Knöpfchen drückt).
Das fände ich außerordentlich schade, zumindest wenn es sich nicht konfigurieren ließe. Für mich war das immer ein guter Hinweis auf meine Funkumgebung. Aus diesem Grund habe ich FHEM auch angewiesen, alle neuen Geräte ausschließlich in einen eigenen Raum zu verfrachten, dann fällt das nämlich auch sofort auf.
Gut, zur Not könnte ich den AskSinAnalyzer eine Weile mitlaufen lassen, aber den haben ja wohl die wenigsten.
Zitat von: Pfriemler am 17 November 2021, 08:38:41
Forum ist auch Hilfe zur Selbsthilfe. Ich fand die Nennung aller Checkpunkte ausreichend - wobei aus meiner Sicht gerade der Hinweis auf das Pairing den besten Hinweis liefert, ob es das eigene oder ein fremdes Gerät ist.
Verstehe leider nicht, was mit "Nennung der Checkpunkte" gemeint sein soll. Generell fällt mir halt auf, dass es grade wieder eine vermehrte Anzahl von Threads gibt, die mehr oder weniger 0 Info enthalten. Dieser hier ist immerhin bei 0.2 gewesen ("habe nur Thermostate")
Zitat
Das fände ich außerordentlich schade, zumindest wenn es sich nicht konfigurieren ließe. Für mich war das immer ein guter Hinweis auf meine Funkumgebung. Aus diesem Grund habe ich FHEM auch angewiesen, alle neuen Geräte ausschließlich in einen eigenen Raum zu verfrachten, dann fällt das nämlich auch sofort auf.
Gut, zur Not könnte ich den AskSinAnalyzer eine Weile mitlaufen lassen, aber den haben ja wohl die wenigsten.
Du kannst gerne zu dem von mir gemachten konkreten Code-Vorschlag an der passenden Stelle was schreiben, ich hänge nicht an einer bestimmten Lösung, weil das für mich selbst komplett irrelevant ist.
Meine Meinung ist: "Fremde" Geräte sollten grundsätzlich nicht automatisch angelegt werden, wenn eine VCCU vorhanden ist. Wer die "braucht", sieht die HmID in der VCCU und kann dann ja manuell anlegen, war er für sinnvoll findet. Genau dieses Verhalten besteht aber mAn. derzeit nicht, obwohl ich das auch so im Ohr hatte, dass VCCU gerade mit diesem Argument beworben worden war.
Aber wie gesagt: Diese Diskusion ist hier falsch!
Okay ich habe an dieser Stelle versagt, obwohl ich schon so lange im Forum hänge :-(
Die lists habe ich jetzt der guten Ordnung halber abgehangen.
Das entscheidende dürfte dann wohl hmId 240271 gewesen sein, Ich habe jetzt alle Geräte aus dem Raum entfernt die kein PairedTo 0x240271 beim Listing gezeigt haben.
Danke für Eure geduldige Unterstützung.
Internals:
CUL868_MSGCNT 8
CUL868_RAWMSG Z0B0106300E2B261234560010
CUL868_RSSI -63.5
CUL868_TIME 2021-11-17 10:54:59
DEF 123456
FUUID 5c500792-f33f-a44f-2069-60165be60903736b
IODev CUL868
LASTInputDev CUL868
MSGCNT 8
NAME cm
NR 32
STATE CUL868:ok
SVN 22175
TYPE CUL_MAX
addr 123456
cnt 0
pairmode 0
retryCount 0
sq 0
READINGS:
2021-11-17 10:11:44 IODev CUL868
2020-05-04 11:57:15 packetsLost 6402
2021-11-17 10:54:59 state CUL868:ok
sendQueue:
Attributes:
IODev CUL868
fakeSCaddr 222222
fakeWTaddr 111111
room Funkzentrale
Internals:
CMDS BbCFiAZEGMKUYRTVWXefmltux
CUL868_MSGCNT 8
CUL868_TIME 2021-11-17 10:54:59
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1034
DeviceName /dev/serial/by-id/usb-busware.de_CUL868-if00@9600
FD 11
FHTID 1034
FUUID 5c500791-f33f-a44f-9b17-90eefd37199ec5c2
NAME CUL868
NR 31
NR_CMD_LAST_H 2
PARTIAL
RAWMSG Z0B0106300E2B26123456001015
RSSI -63.5
STATE Initialized
TYPE CUL
VERSION V 1.61 CUL868
devioNoSTATE 1
initString X21
Zr
Za123456
Zw111111
MatchList:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2021-11-17 10:08:39 cmds B b C F i A Z E G M K U Y R T V W X e f m l t u x
2021-11-17 02:29:01 credit10ms 6880
2021-11-17 10:54:59 state Initialized
XMIT_TIME:
1637140304.84677
1637140310.04864
Attributes:
devStateIcon .*:cul_868
hmId 240271
icon cul_868
rfmode MAX
room Funkzentrale
Nichts für ungut, aber du solltest dich nochmal mit den grundsätzlichen Zusammenhängen befassen - v.a. auch, was eine VCCU ist und wann man Devices besser auf "ignore" stellt.
Leider schwahnt mir Schlimmes, wenn du nach den hier genannten Stichworten ein list von einem CUL im MAX-Modus anhängst...
Zitat von: Beta-User am 17 November 2021, 11:38:44
Nichts für ungut, aber du solltest dich nochmal mit den grundsätzlichen Zusammenhängen befassen - v.a. auch, was eine VCCU ist und wann man Devices besser auf "ignore" stellt.
Leider schwahnt mir Schlimmes, wenn du nach den hier genannten Stichworten ein list von einem CUL im MAX-Modus anhängst...
Jep, noch dazu wo es ja ähnlich verwirrende Fragen bzgl. MAX gibt: https://forum.fhem.de/index.php/topic,123848.msg1184070.html#msg1184070
Evtl. erst mal sortieren was du nun hast: MAX! oder Homematic (per CUL_HM) oder beides...
Wenn beides, dann mal ordnen!
Wenn nur eines davon: entscheiden was nun ;)
Ja, kann verwirren, weil ein CUL nun mal "vieles"
"alles" kann (aber nichts wirklich gut ;) zumindest Homematic eher schlecht als recht 8) )...
EDIT: aber verm. beides? weil du ja folgendes IO (zusätzlich) hast
Zitat
2021-11-16 17:56:13 IODev hmusb
Gruß, Joachim
jupp beides und gerne würde ich ja was tolles modernes verwenden was alles einfacher macht; aber ungerne alles was ich mal gekauft habe wegwerfen.
Zitat von: mfeske am 17 November 2021, 13:42:39
jupp beides und gerne würde ich ja was tolles modernes verwenden was alles einfacher macht; aber ungerne alles was ich mal gekauft habe wegwerfen.
Keiner hat was von wegwerfen gesagt...
Und auch ich habe noch Homematic "Classic"...
...hatte auch mal ganz zu beginn mit MAX! angefangen (mal zum "Spielen" ein paar Geräte).
Allerdings mich dann doch für Homematic entschieden.
Und mehrere Systeme verwenden ist ja dank fhem kein Problem...
...ABER: man selbst sollte schon wissen welches Gerät/Device nun welches System als Basis hat!
Weil sonst ist es nat. schwer und unübersichtlich...
Und eigentlich sollte man das doch leicht anhand von IODev o.ä. Attributen/Readings der Devices erkennen können.
Oder auch TYPE...
Damit kann man ja dann die lists entsprechend "filtern" und man erhält dann nur Devices von besagtem "Typ" (System etc.).
-> devspec
Zitat von: commandref"
Geräte-Spezifikation (devspec)
[EN DE]
Die Befehle attr, set, get, usw. attr, deleteattr, displayattr, delete, get, list, set, setreading, setstate, trigger können eine komplexere Gerätespezifikation als Argumente enthalten, die auch eine Anzahl von Geräten betreffen kann. Eine Gerätespezifikation kann folgendes sein:
ein einzelner Gerätename. Dies ist der Normalfall
eine durch Komma(,) getrennte Liste von Gerätenamen
ein regulärer Ausdruck
ein NAME=WERT Ausdruck, wo NAME ein "Internal" Wert wie TYPE ist, ein Reading-Name oder ein Attribut. WERT ist ein regulärer Ausdruck. Um die Bedingung zu negieren, muss NAME!=WERT verwendet werden. Um die Suche einzugrenzen, kann man als Praefix i: für internal Werte, r: für Reading-Namen und a: für Attribute verwenden, siehe das Beispiel unten. Groß-/Kleinschreibung wird durch die Verwendung von ~ oder !~ ignoriert.
Falls die Spezifikation von :FILTER=NAME=WERT gefolgt wird, dann wird die zuvor gefundene Liste durch diesen neuen Ausdruck gefiltert.
Beispiele:
set lamp1 on
set lamp1,lamp2,lamp3 on
set lamp.* on
set room=kitchen off
set room=kitchen:FILTER=STATE=on off
set room=kitchen:FILTER=STATE!=off off
list disabled=
list room~office
list TYPE=FS20 STATE
list i:TYPE=FS20 STATE
Bemerkungen:
die Spezifikation kann keine Leerzeichen enthalten.
falls ein Gerätename exakt dem Spezifikation entspricht, dann werden keine reguläre Ausdrücke oder Filter ausgewertet.
zuerst wird die durch Komma getrennte Spezifikation abgearbeitet, dann folgen die regulären Ausdrücke und die Filter
die Befehlszeile kann die selbe Gerätebezeichnung mehrfach enthalten z.B.: "set lamp3,lamp3 on". Lamp3 wird hier zwei Mal eingeschalten.
um Strukturen mit komplexeren Anforderungen zu realisieren lesen Sie bitte den Abschnitt zu structure.
Dann hat man schon mal "Ordnung" im Sinne einer "Übersicht".
Und dann muss man halt Device für Device durchgehen und schauen:
- ob es einem selbst gehört oder man sich was "eingefangen" hat
- ob es i.O. ist und funktioniert
- usw.
Aber durcheinander haben und dann durcheinander posten bringt uns auch durcheinander...
...und dann ist Hilfe halt schwer...
Gruß, Joachim
Zur Klarstellung:
Zitat von: Beta-User am 17 November 2021, 09:19:19
Verstehe leider nicht, was mit "Nennung der Checkpunkte" gemeint sein soll.
Ja, war missverständlich. Ich meinte die von Dir und anderen genannten Lösungsvorschläge, die der Fragesteller (der schon in der Formulierung anfängertypische Wissenslücken in der Homematic-Problematik offenbart, was aber kein Mangel an sich ist, solange man dazuzulernen bereit ist) auf seine Schilderung genannt bekommen hat: a) prüfe anhand "model" ob Dir die Geräte bekannt vorkommen, b) prüfe am Alter der readings ob die Meldungen aktuell sind oder Leichen c) prüfe am "pairedTo" ob die Geräte überhaupt von Dir irgendwann mal angelernt wurden - und welche hmID man selbst betreibt, sollte man schon recht bald nicht mehr nachschlagen müssen ;D
Damit hatte er eigentlich genug Input um weiterzukommen. Das fehlende "list" hat uns hier nur daran gehindert, das Problem selbst zu erkennen und ihm konkret zu sagen was bei ihm falsch ist. Darum hatte er auch erst gar nicht gebeten - er wollte Hinweise wie er es selbst herausbekommt. Und die hat er bekommen.
Ich gehöre dann wohl zu der Minderheit, die eine Problemschilderung einer ellenlangen Codeablage hier im Forum vorziehen...
Zu den vccu-Fertigkeiten wirklich an anderer Stelle mehr, du hast völlig recht.
Sah das auch wie Joachim: Offenbar benutzt mfeske ein "CUL868" für MAX! und einen "hmusb" für Homematic. Vielleicht war der CUL zuvor oder temporär für Homematic benutzt und die hmID steht da eben noch (überflüssigerweise) drin.
Jetzt will ich mal hoffen, dass die genannte hmID auch wirklich seine aktuelle war, sonst ist fröhliches Wiederpairen angesagt.
mfeske, magst Du uns noch kurz verraten, was genau dein "hmusb" ist? Attribut "model" reicht ...
Zitat von: Pfriemler am 17 November 2021, 16:35:12
Ich gehöre dann wohl zu der Minderheit, die eine Problemschilderung einer ellenlangen Codeablage hier im Forum vorziehen...
Ich bin auch immer mal wieder hin- und hergerissen und finde die gelegentlich anzutreffenden "Total-postings" meistens auch grauenhaft.
Es ist aber (leider) eine Kunst, sich auf das wesentliche zu beschränken, die nur wenige beherrschen, und dann finde ich es hilfreich, den "hingeworfenen Heuhaufen" zumindest mal schnell abscannen zu können...
Ein "vorbildlicher User" wird auch den von ihm zum posten vorgesehenen Content erst mal sammeln und _sichten_ müssen, und wer das tut, beantwortet sich eigentlich in der Regel die betreffenden Fragen direkt selbst => posting nicht mehr erforderlich... (Geht mir nicht selten auch so ähnlich, übrigens ;) ).