Hallo,
nach meinem Umzug möchte ich nun meine 4 HM-SEC-SD Installieren.
Ich möchte das bei einer Auslösung nach und nach alle Alarm geben. Jedoch per Push NUR den Rauchmelder bekommen der Ausgelöst hat.
Zusätzlich möchte ich die Rauchmelder auch als ALARM nutzen.
Muss ich alle Rauchmelder in ein Team packen oder virtueller TeamLead ?
Auch muss ich noch 2 Rauchmelder erweitern. Wenn ich keine HM-SEC-SD mehr bekomme muss ich wohl HM-SEC-SD2 hinzupacken aber das geht nicht im gleichen Team oder?
Ganz schön verwirrend :D
Hi,
also am Besten so machen wie im Wiki -> https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder
Hat bei mir ohne Probleme funktioniert.
Ob das mit dem Team mit den neuen geht weiß ich nicht. Aber warum eigentlich nicht? Der Teamlead ist noch bloß ein Peer?
Gruß Otto
ja genau das hab ich mir angeschaut aber nicht so durchgeblickt. Hatte es damals irgendwie hingefummelt das alle Alarm geben wenn einer auslöst das war es aber schon. Es gibt da ja mehrer möglichkeiten. Jedoch rauchmelder als eigenes Team oder mehrer zusammen in einem Team ..
Also:
alle "jungfräulich"
erstmal pairen mit FHEM, das muss sauber funktionieren!
dann virtuellen Teamlead erstellen, so wie es im "Buch" steht
Dann mit virtuellen Teamlead peeren.
So habe ich es gemacht. 8)
ich habe die Teile einfach als Team definiert und die heissen alle hm.rm.<x>
im Alias Attribut steht dann drinnen wo der Rauchmelder installiert ist
mein Notify funktioniert eingentlich perfekt :-)
defmod noty.feuer notify hm.rm..:smoke_detect.* {\
DebianMail('Wuppi@domain1.irgendwo,partner@domain1.irgendwo', "Feueralam", "Rauch gemeldet von " . AttrVal($NAME, 'alias', "unbekannt"));;\
PushInfo("Feueralarm", "Rauch gemeldet von " . AttrVal($NAME, 'alias', "unbekannt"));;\
fhem("set hm.rollade.. on");;\
fhem("set hm.dim.1 on-for-timer 900");;\
fhem("set hm.pwm.1.sw on-for-timer 900");;\
fhem("set hm.dim.3 on-for-timer 900");;\
fhem("set hm.sw.6 on-for-timer 900");;\
}\
attr noty.feuer room Notify,Sicherheit
attr noty.feuer verbose 5
hm okay Danke. Ja Team funktioniert Teamcall auch.
Das hier hatte ich früher .. jedoch haben mir ALLE dann Push geschickt weil die nach und nach ja ausgelöst wurden. Kann ich den Team ( Rauchmelder_Team ) nicht abfragen wer ausgelöst hat und nur dafür Push ?
define Noti_Dach.RauchmelderPushOn notify Dach.Rauchmelder:smoke-Alarm.* {fhem ("set pushch message 'Rauchmelder Dach AKTIV' 'Achtung Rauchmelder Dach hat ausgeloest!!!!!' '' 0 ''")}
define Noti_Dach.RauchmelderPushOff notify Dach.Rauchmelder:off {fhem ("set pushch message 'Rauchmelder Dach INAKTIV' 'Entwarnung Rauchmelder Dach' '' 0 ''")}
define Noti_Keller.RauchmelderPushOn notify Keller.Rauchmelder:smoke-Alarm.* {fhem ("set pushch message 'Rauchmelder Keller AKTIV' 'Achtung Rauchmelder Keller hat ausgeloest!!!!!' '' 0 ''")}
define Noti_Keller.RauchmelderPushOff notify Keller.Rauchmelder:off {fhem ("set pushch message 'Rauchmelder Keller INAKTIV' 'Entwarnung Rauchmelder Keller' '' 0 ''")}
define Noti_Erdgeschoss.RauchmelderPushOn notify Erdgeschoss.Rauchmelder:smoke-Alarm.* {fhem ("set pushch message 'Rauchmelder Erdgeschoss AKTIV' 'Achtung Rauchmelder Erdgeschoss hat ausgeloest!!!!!' '' 0 ''")}
define Noti_Erdgeschoss.RauchmelderPushOff notify Erdgeschoss.Rauchmelder:off {fhem ("set pushch message 'Rauchmelder Erdgeschoss INAKTIV' 'Entwarnung Rauchmelder Erdgeschoss' '' 0 ''")}
ich habe die als Team direkt verbunden - ohne den TeamLead von FHEM und es kommt nur der auslösende Rauchmelder als Nachricht bei mir an
Hatte letzten Monat 2 Fehlalarme (2 mal kleine Tiere :-( ) und konnte es noch einmal in den Logs kontrollieren
Alle machen Radau, aber nur der auslösende Meldet sich bei FHEM :-)
Ich habe 3 Melder mit virtuellem Teamlead.
Ich finde den Meldungsverlauf logisch
2016-12-18_05:56:16 RmFlur smoke_detect: RmFlur
2016-12-18_05:56:16 RmFlur smoke-Alarm_03
2016-12-18_05:56:16 RmFlur trigLast: Rauchmelder_Team:200
2016-12-18_05:56:16 RmFlur trig_Rauchmelder_Team: 200_3
2016-12-18_05:56:16 RmFlur trigLast: Rauchmelder_Team:200
2016-12-18_05:56:16 RmFlur trig_Rauchmelder_Team: 200_3
2016-12-18_05:56:17 RmFlur trigLast: Rauchmelder_Team:200
2016-12-18_05:56:17 RmFlur trig_Rauchmelder_Team: 200_3
2016-12-18_05:56:46 RmFlur smoke_detect: none
2016-12-18_05:56:46 RmFlur off
2016-12-18_05:56:46 RmFlur trigLast: Rauchmelder_Team:1
2016-12-18_05:56:46 RmFlur trig_Rauchmelder_Team: 1_4
2016-12-18_05:56:47 RmFlur trigLast: Rauchmelder_Team:1
2016-12-18_05:56:47 RmFlur trig_Rauchmelder_Team: 1_4
2016-12-18_05:56:48 RmFlur trigLast: Rauchmelder_Team:1
2016-12-18_05:56:48 RmFlur trig_Rauchmelder_Team: 1_4
2016-12-18_05:57:47 RmFlur smoke_detect: RmFlur
2016-12-18_05:57:47 RmFlur smoke-Alarm_05
2016-12-18_05:57:47 RmFlur trigLast: Rauchmelder_Team:200
2016-12-18_05:57:47 RmFlur trig_Rauchmelder_Team: 200_5
2016-12-18_05:57:47 RmFlur trigLast: Rauchmelder_Team:200
2016-12-18_05:57:47 RmFlur trig_Rauchmelder_Team: 200_5
2016-12-18_05:57:48 RmFlur trigLast: Rauchmelder_Team:200
2016-12-18_05:57:48 RmFlur trig_Rauchmelder_Team: 200_5
2016-12-18_05:58:02 RmFlur smoke_detect: none
2016-12-18_05:58:02 RmFlur off
2016-12-18_05:58:02 RmFlur trigLast: Rauchmelder_Team:1
2016-12-18_05:58:02 RmFlur trig_Rauchmelder_Team: 1_6
2016-12-18_05:58:03 RmFlur trigLast: Rauchmelder_Team:1
2016-12-18_05:58:03 RmFlur trig_Rauchmelder_Team: 1_6
2016-12-18_05:58:03 RmFlur trigLast: Rauchmelder_Team:1
2016-12-18_05:58:03 RmFlur trig_Rauchmelder_Team: 1_6
2016-12-18_05:56:16 RmAZ smoke_detect: RmFlur
2016-12-18_05:56:16 RmAZ smoke-Alarm_03
2016-12-18_05:56:46 RmAZ smoke_detect: none
2016-12-18_05:56:46 RmAZ off
2016-12-18_05:57:46 RmAZ smoke_detect: RmFlur
2016-12-18_05:57:46 RmAZ smoke-Alarm_05
2016-12-18_05:58:02 RmAZ smoke_detect: none
2016-12-18_05:58:02 RmAZ off
2016-12-18_05:56:16 RmSZ smoke_detect: RmFlur
2016-12-18_05:56:16 RmSZ smoke-Alarm_03
2016-12-18_05:56:46 RmSZ smoke_detect: none
2016-12-18_05:56:46 RmSZ off
2016-12-18_05:57:47 RmSZ smoke_detect: RmFlur
2016-12-18_05:57:47 RmSZ smoke-Alarm_05
2016-12-18_05:58:02 RmSZ smoke_detect: none
2016-12-18_05:58:02 RmSZ off
Alle melden sich bei FHEM, der auslösende Melder ist klar identifizierbar.
Was man daraus macht ist doch jedem seine Sache. Alles ist möglich.
Wer der Teamlead ist doch völlig egal, der virtuelle macht doch nur den physischen ersetzbar. Zumindest verstehe ich das so.
Gruß Otto
also ich habe meine Rauchmelder nun umbenannt in hm.rm.******
Das notify scheint nicht zu klappen:
define noty.feuer notify hm.rm..:smoke_detect.* {\
pushch("Feueralarm", "Rauch gemeldet von " . AttrVal($NAME, 'alias', "unbekannt"));;\
}\
attr noty.feuer room Notify,Sicherheit
attr noty.feuer verbose 5
Nutze Pushbulled das solte so ja klappen? Oder macht das AttrVal Probleme ?
Dieses regEx hm.rm.. match wahrscheinlich nicht auf hm.rm.****** - wo ich annehme die ****** stehen für irgendwelche Zeichen.
Ein Punkt im regEx match auf EIN beliebiges Zeichen. Ein .* würde auf beliebige Zeichen in beliebiger Anzahl matchen.
Gruß Otto
hmm also hm.rm.*.:smoke_detect.* ?
Teste doch das regEx für das Gerät erst mal im Eventmonitor.
Ich würde hm.rm.* testen ;)
Eventmonitor ? Naja ich will das lästige Auslösen des Rauchmelders nicht zu oft machen :)
Nur hm.rm.* würde dich auch bei den Status meldungen auslösen das smoke_detect muss ich ja schon reinfummeln.
Hatte es aus dem Beispiel oben genommen dort scheint das ja so zu funktionieren o_O
Du verstehst mich falsch :-[ Ein notify triggert auf
Gerätename:Event
Der Doppelpunkt ist dabei künstlich der Trenner zwischen Gerätename und Event, der ist im eigentlichen Event nicht vorhanden. Am Ende ist aber Gerätename ein regEx und Event auch ein regEx also regEx:regEx
Für den Gerätenamen habe ich hm.rm.* vorgeschlagen, dein Vorschlag mit hm.rm.*. macht irgendwie keinen Sinn -> beliebig viele Zeichen plus noch eins ;D
Den Gerätenamen solltest Du schmerzfrei im Eventmonitor testen, einfach einen Statusrequest auslösen ganz ohne Lärm.
Der Eventteil smoke_detect.* wird schon funktionieren.
Gruß Otto
super das hab ich verstanden. Leider wird bei Status des einzelnen Rauchmelders nur im Team was angezeigt
2017-08-07 09:26:42 CUL_HM Rauchmelder_Team off
und nicht vom Rauchmelder direkt.
Aber hm.rm.*:smoke_detect.* sollte nun funktionieren. Werd ich später mal testen.
Meine Rauchmelder heißen alle Rmxxx
Im Eventmonitor sieht es dann so aus, wenn ich einen set <Rmxxx> statusRequest am jeweiligen Rm mache:
Events (Filter: Rm.*)
2017-08-07 09:15:42 CUL_HM RmFlur battery: ok
2017-08-07 09:15:42 CUL_HM RmFlur level: 1
2017-08-07 09:15:42 CUL_HM RmFlur off
2017-08-07 09:31:33 CUL_HM RmSZ battery: ok
2017-08-07 09:31:33 CUL_HM RmSZ level: 1
2017-08-07 09:31:33 CUL_HM RmSZ off
Danke event-on-update-reading .* war der Grund :) Funktioniert nun alles.
Mit $name bekomme ich das Gerät angezeigt. Aber mit was bekomme ich das hinter smokedetect ? $event ?
Dann würde ich mir das mit dem Push schicken lassen wegen Entwarnung. Bei einem echten Feuer wird er wohl kaum dann als nächstes die entwarnung schicken :)
mit $EVENT bzw auch die einzelnen Teile mit $EVTPARTx
Danke Otto123 für die Unterstützung ... ich hatte in den letzten Tagen super wenig Zeit :-(
bei mir sind dir Rauchmelder von 1-x durchnummeriert und noch nicht zweistellig - deshalb der .. obwohl es bestimmt besser \.. lauten sollte ;-)
Hallo und Guten Tag in die Runde :)
ich muss mich hier mal einklinken...hab mir auch ein Set von 3 HM-SEC-SD-2 bestellt und möchte wissen, wenn ich sie erst in FHEM paire und mit dem virtuellen Lead peere, ob sie dann trotzdem ohne die Zentrale auch untereinander kommunizieren können (falls die mal ausfällt)?
Gruß Dusti
Hallo Dusti,
JA
Gruß Otto
Danke Otto...
also entgegen dem Wiki erst mit FHEM pairen, den virtuellen Teamlead einrichten, dann alle mit dem Leader peeren und dann auch noch alle untereinander? Oder fällt das "untereinander" dann weg?
Gruß Dusti
Entgegen dem Wiki? Wo steht das? Hast Du einen Link? :-X
Mit FHEM pairen und kontrollieren!!! Alles muss sauber sein!
Teamlead anlegen
mit dem Teamlead peeren.
Und nicht untereinander peeren - das genau ist ja der Sinn vom Teamlead!!! Wobei ich nicht genau weiß was man machen soll mit der neuen Funktion der Verkettung bei den SD-2 ich habe nur die SD
https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#Hinweise_zum_Betrieb_mit_FHEM
Gruß Otto
Ok...hab ich vielleicht falsch verstanden :-\
Und die gemeinsame HMId nach dem Peeren mit dem virtuellen TeamLead ermöglicht dann die Kommunikation untereinander ohne die Zentrale ja?
Genau diese interne Verkettung bei den SD-2 meinte ich...
Gruß Dusti
Zitat von: dusti64 am 25 November 2017, 12:34:06
Und die gemeinsame HMId nach dem Peeren mit dem virtuellen TeamLead ermöglicht dann die Kommunikation untereinander ohne die Zentrale ja?
Alle haben die peerId des virtuellen Teams und signalisieren sich gegenseitig ohne die Zentrale. Die Zentrale hört eigentlich nur mit.
Gruß Otto
Ok :) dank dir und werde mein Glück versuchen!
Gruß Dusti
Update:
Eingerichtet, getestet (auch ohne Zentrale) und für gut befunden (y)
Gruß Dusti
Hallo in die Runde,
wie sind denn eure Langzeiterfahrungen mit Fehlalarmen, speziell beim HM-SEC-SD-2? Die Rezensionen im großen A-Versandhaus sind ja doch recht diffus - von "kaum" bis "ständig"... Würdet ihr, wenn ihr nochmal vor der Wahl stündet, wieder den HM nehmen?
Danke!
8 mal HM-SEC-SD-2 seit längerem im Einsatz. Noch nie ein Fehlalarm gehabt.
ZitatHat bei mir ohne Probleme funktioniert.
Hallo Otto, bei mir hat das nach der Anleitung im Wiki leider nicht so einfach funtkioniert. Es scheitert schon am folgenden Satz:
Nach der Definition bitte überprüfen, dass TeamDev das Attribut (attr) IODev bzw. IOgrp gesetzt hat (das sollte normalerweise automatisch passieren)! Am Besten die Konfiguration mit HMinfo configCheck prüfen, die ordnungsgemäße Funktion des TeamDev ist wichtig für den Erfolg des folgenden Peerings der Rauchmelder.Er trägt das IODev nicht von alleine ein, sondern da steht bei mir Undefined. Aber was muss ich denn da eintragen dass es funktioiert?
Hatte mein HM_MOD_RPI_PCB eingetragen, aber das scheint nicht des Rätsels Lösung zu sein.
Hier mein List:
Internals:
DEF 123456
IODev HM_MOD_RPI_PCB
NAME SmokeDetectorTeamDev
NOTIFYDEV global
NR 39
NTFY_ORDER 50-SmokeDetectorTeamDev
STATE ERR_IOdev_undefined
TYPE CUL_HM
channel_01 RauchmelderTeam
READINGS:
2018-11-21 18:17:34 state ERR_IOdev_undefined
helper:
HM_CMDNR 237
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
Attributes:
IODev HM_MOD_RPI_PCB
expert 2_raw
group Rauchmelder
model virtual_1
room CUL_HM
subType virtual
webCmd virtual
Vielen Dank schon mal. :)
Hi,
naja wenn DU ein VCCU hast, sollte attr IOgrp gesetzt sein.
Wenn nicht und Dein HM IO wirklich so heißt: HM_MOD_RPI_PCB
dann wäre der Eintrag richtig!
Hast Du HMinfo definiert und configcheck probiert?
Gruß Otto
Zitatnaja wenn DU ein VCCU hast, sollte attr IOgrp gesetzt sein.
Hi Otto, ja ich habe eine VCCU und habe zusätzlich jetzt noch das RauchmelderTeamDev angelegt. Falls du das meinst.
ZitatHast Du HMinfo definiert und configcheck probiert?
Ja, habe ich auch gemacht. Aber da tut sich bei mir gar nichts. Da hätte ich erwartet dass dass ich da irgendetwas zurückgeliefert bekomme.
Mein Logifle ist auch voll mit folgendem und ähnlichen Einträgen.
HM_MOD_RPI_PCB: Unknown code A0FA2861051B1F70000000AB8DD0A6440::-37:HM_MOD_RPI_PCB, help me!
Viele Grüße
Thomas
Zitat von: ToM_ToM am 22 November 2018, 18:45:49
Hi Otto, ja ich habe eine VCCU und habe zusätzlich jetzt noch das RauchmelderTeamDev angelegt. Falls du das meinst.
Nein das meinte ich nicht ???
Machst Du bitte mal ein list HM_MOD_RPI_PCB und ein list "Deiner VCCU ".
Gruß Otto
Guten Morgen Otto,
anbei die Lists:
HM_MOD_RPI_PCB
Internals:
AssignedPeerCnt 9
CNT 28
Clients :CUL_HM:
DEF /dev/ttyS1
DEVCNT 28
DevState 99
DevType UART
DeviceName /dev/ttyS1@115200
FD 10
LastOpen 1542879211.24781
NAME HM_MOD_RPI_PCB
NR 22
PARTIAL
RAWMSG 040200
RSSI -36
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model HM-MOD-UART
msgLoadCurrent 0
msgLoadHistory 0/0/0/0/0/0/0/0/0/0/0/0
msgLoadHistoryAbs 0/0/0/0/0/0/0/0/0/0/0/0/0
owner 6A60AE
Helper:
CreditTimer 5024
FW 66561
Initialized 1
SendCnt 44
AckPending:
LastSendLen:
3
3
Log:
IDs:
PeerQueue:
PendingCMD:
RoundTrip:
Delay 0.00301599502563477
loadLvl:
lastHistory 1542954217.20669
MatchList:
1:CUL_HM ^A......................
Peers:
5E71CF +5E71CF,00,00,00
658B78 +658B78,00,00,00
658EF8 +658EF8,00,00,00
673DAD +673DAD,00,00,00
673DBD +673DBD,00,00,00
673E0C +673E0C,00,00,00
673E65 +673E65,00,00,00
67405E +67405E,00,00,00
674073 +674073,00,00,00
READINGS:
2018-11-22 10:33:37 D-HMIdAssigned 6A60AE
2018-11-22 10:33:37 D-HMIdOriginal 6A60AE
2018-11-22 10:33:37 D-firmware 1.4.1
2018-11-22 10:33:37 D-serialNr PEQ0531232
2018-11-22 10:33:31 D-type HM-MOD-UART
2018-11-22 10:33:37 cond ok
2018-11-23 05:33:32 load 0
2018-11-22 11:33:20 loadLvl low
2018-11-22 10:33:31 state opened
helper:
Attributes:
hmId 6A60AE
room SYSTEM->Fhem
VCCU
Internals:
DEF 6A60AE
IODev HM_MOD_RPI_PCB
NAME VCCU
NOTIFYDEV global
NR 23
NTFY_ORDER 50-VCCU
STATE HM_MOD_RPI_PCB:UAS,
TYPE CUL_HM
assignedIOs HM_MOD_RPI_PCB
READINGS:
2018-11-22 10:33:33 state HM_MOD_RPI_PCB:UAS,
helper:
HM_CMDNR 134
mId FFF0
regLst ,0
rxType 1
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu VCCU
ioList:
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
Attributes:
IODev HM_MOD_RPI_PCB
IOgrp VCCU
expert 2_raw
model CCU-FHEM
room SYSTEM->Fhem
subType virtual
webCmd virtual:update
Viele Grüße
Thomas
warum hat deine vccu kein attr IOList?
Zitatwarum hat deine vccu kein attr IOList?
Hallo Frank,
was soll denn da drin stehen?
Habe 3 Systeme am laufen und bei keinem habe ich dieses Attribut gesetzt. Konnte auch in der Commandref nichts dazu finden was darauf hinweist dass ich da zwingend was eintragen muss.
VG, Thomas
ohne attr iolist ist deine vccu nutzlos.
da stehen die namen der gateways drin, die sie verwalten soll.
im wiki steht auch nichts?
Zitatohne attr iolist ist deine vccu nutzlos.
Dem kann ich nicht 100%tig zustimmen. Die VCCU funktioniert trotzdem. Auch kann ich relativ einfach zwischen HM-LAN, CUL-Stick und Platine wechseln sowie Events der VCCU verarbeiten.
Im Wiki steht etwas über die IOList. Aber ich verstehe trotzdem noch nicht wie mir das jetzt in meinem Fall mit dem RauchmelderTeam weiterbringt.
Wie müsste ich es denn konfigurieren dass das Rauchmelder-Team funktioniert? Was müsste ich dafür bei IOList, IODev oder IOgrp eintragen?
Viele Grüße
Thomas
attr VCCU IOList HM_MOD_RPI_PCB
Oder hast Du drei IOs in einem System?
Dann gehören alle drei IOs in die Liste.
Oder hast Du drei getrennte FHEM Systeme?
Ansonsten ist es, wie Frank sagt, eigentlich witzlos. Ich denke der komische Fehler kommt von dem fehlendem Eintrag.
Was bist Du der Meinung funktioniert an der VCCU? ???
Wie meinst Du das, Du kannst zwischen HM-LAN, CUL-Stick und Platine wechseln?
Gruß Otto
Hallo Otto,
nein ich habe 3 unterschiedliche Systeme an verschiedenen Orten.
So witzlos ist das mit der VCCU nicht. Aktuell verwende ich den HM_MOD_RPI_PCB. Dank der VCCU kann ich aber den im Falle eines Defekts einfach abziehen und z.B. gegen den HMLAN-Adapter oder CUL-Stick tauschen. Zusätzlich kommunizieren meine Taster mit der VCCU und die Events fange ich von den virtuellen Kanälen der VCCU ab.
Aber die läuft ja sauber. Ich habe ja nur das Problem mit dem neuen Rauchmelder TeamDev. Hatte jetzt nochmal alles neu angelegt und es geschafft, einen der Rauchmelder in das Team aufzunehmen. Aber die anderen wollen noch nicht.
Viele Grüße
Thomas
über die vccu wird sicherlich nicht kommuniziert.
dir fällt ja nicht mal der problematische state auf:
2018-11-22 10:33:33 state HM_MOD_RPI_PCB:UAS,
wenn es funktionieren soll, muss dort "ok" stehen und nicht "uas" => unassigned.
zeig doch mal ein "get hminfo configCheck".
aber jeder wie er will. ;)
Zitatüber die vccu wird sicherlich nicht kommuniziert.
Guten Morgen Frank,
bei dieser Konfiguration wo ich die Rauchmelder hinzufügen möchte, kann es sein. Auf meinem anderen System steht bei State: CMDs_done
Anbei mein ConfigCheck:
configCheck done:
missing register list
HM_658B78: RegL_00.,RegL_01.
HM_658EF8: RegL_00.,RegL_01.
HM_67405E: RegL_00.
peer list incomplete. Use getConfig to read it.
incomplete: HM_658B78:
incomplete: HM_658EF8:
peer not defined
HM_673DAD id:5E71CF01
HM_673E0C id:5E71CF01
HM_674073 id:5E71CF01
peer not verified. Check that peer is set on both sides
SmokeDetectorTeam p:HM_673DAD
SmokeDetectorTeam p:HM_673E0C
SmokeDetectorTeam p:HM_67405E
SmokeDetectorTeam p:HM_674073
peering strange - likely not suitable
HM_67405E not peered!! add SD to any team !!
PairedTo missing/unknown
HM_658B78
HM_658EF8
Viele Grüße
Thomas
Hallo Thomas,
ich empfehle Dir eine saubere Konfiguration der VCCU und Deiner HM Komponenten bezüglich der Konfiguration mit IOgrp.
Dann solltest Du die Liste aus configCheck solange abarbeiten bis dort nichts mehr steht.
Dann wird auch die Sache mit dem Rauchmelder funktionieren.
Aber - dein System. Dein Betriebsregime. ::)
Was Du mit den IOs und der VCCU machst, hat sicher miteinander gar nichts zu tun. Solange die IOList leer ist, arbeiten aus meiner Sicht die IOs autark und nicht mit der VCCU. Aber kann sein da laufen Dinge ab die nicht dokumentiert sind. ;)
Gruß Otto
Zitatich empfehle Dir eine saubere Konfiguration der VCCU und Deiner HM Komponenten bezüglich der Konfiguration mit IOgrp.
Hallo Otto,
nur leider werde ich aus dem Wiki, Forum und Commandref nicht ganz schlau wie diese "saubere" Konfiguration auszusehen hat.
Ich habe jetzt nochmal alles von vorne gemacht und festgestellt dass das HM_MOD_RPI_PCB und die VCCU nicht die gleiche HMId haben dürfen. Dann funktioniert auch die VCCU.
Habe mehrfach das WIKI immer wieder von vorne durchgearbeitet. Manchmal habe ich ein Team mit 2 Rauchmeldern hinbekommen die auch auf mein TeamCall reagiert haben, aber mehr Rauchmelder waren nicht Teamfähig.
Da ich Angst habe dass wenn ich die noch ein paar Mal anlerne und resete, irgendwann die Batterien leer sind, muss ich dan dieser Stelle leider kapitulieren.
Trotzdem nochmal vielen Dank für eure Mühe.
Zitat von: ToM_ToM am 24 November 2018, 12:03:30
und festgestellt dass das HM_MOD_RPI_PCB und die VCCU nicht die gleiche HMId haben dürfen. Dann funktioniert auch die VCCU.
Das ist großer Quatsch!
Im obigen Post hat Dein HM_MOD_RPI_PCB und die VCCU die gleiche hmId 6A60AE!
Was Du zur richtigen Konfiguration der VCCU tun musst habe ich schon gesagt, die prinzipielle Einrichtung steht hier ->
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
konkret steht die Einrichtung hier -> https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Definition_der_VCCU
Vor allem wird dort der Umgang mit der hmId erklärt!
Das will ich nicht nochmal abschreiben, konkrete Fragen zu den Schritten aber gern beantworten.
Wenn Du die VCCU richtig konfiguriert hast, brauchst Du beim IO keine hmId mehr extra zu setzen.
Gruß Otto
ZitatDas ist großer Quatsch!
Hätte ich auch gedacht, da ich bei meiner anderen Konfiguration mit dem HMLAN-Adapter die gleiche HMId für HMLAN und VCCU verwende. Beim HM_MOD_RPI_PCB kommt aber in der VCCU bei gleicher HMId immer als
state: HM_MOD_RPI_PCB:UAS was laut Aussage von Frank auf einen Fehler hinweist.
VG, Thomas
Du willst es nicht verstehen oder? :'(
Es fehlt attr VCCU IOList HM_MOD_RPI_PCB dann ist der "Fehler" weg.
UAS steht unassigned, die VCCU merkt da ist was, es ist ihr aber nicht zugeordnet.
ZitatDu willst es nicht verstehen oder? :'(
Hallo Otto, das hat nichts mit "nicht wollen" zu tun! Ich versuche es logisch nachzuvollziehen. Das Attribut habe ich bei meiner anderen Konfiguration auch nicht gesetzt und es funktioniert. Aber egal... selbst wenn ich es hier setze, macht das keinen Unterschied. Der Fehler scheint vermutlich irgendwo anders zu liegen.
falsch bleibt falsch,
egal wieviele falsche installationen du noch heranziehst.
vielleicht stimmt der state (mit attr iolist) nach einem "set vccu update"?
Ich weiß nicht was Du damit meinst: "meiner anderen Konfiguration auch nicht gesetzt und es funktioniert." ?
Was funktioniert denn Deiner Meinung nach an der VCCU? Sie tut nichts und macht keine Fehler? Ich zitiere mal das Wiki
ZitatDurch das Pairen der Geräte mit einer virtuellen CCU ergeben sich folgende Vorteile:
Die Verwendung mehrerer I/O-Devices wird möglich. Das sorgt für Redundanz (Ausfallsicherheit) und/oder Reichweiten-Vergrößerung.
Der Tausch eines I/O-Devices ist transparent für gepairte Geräte.
Die VCCU stellt virtuelle Kanäle zur Verfügung, mit denen HomeMatic-Geräte gepeert werden können.
"Geordnete" Termination von Nachrichten. (Da die üblichen Funkschnittstellen (wie CUL im HM-Mode oder HM-LAN-Konfigurator) relativ "dumm" sind, führen viele Zustände zu den bekannten "Help me" Einträge im Log.)
Die Verwendung mehrer IOs verhinderst Du indem du attr IOList nicht setzt!
Den transparenten Tausch von IOs verhinderst Du indem du attr IOList nicht setzt! Du machst ihn sicherlich einfach in dem Du "manuell" die hmId änderst.
Verwendest Du virtuelle Kanäle der VCCU? Die dürften nicht funktionieren ohne korrekte Konfiguration.
Die Verhinderung von help me Einträgen funktioniert bei Dir nicht, wie Du selbst schreibst.
Du versucht Deine Fehlkonfiguration logisch nachzuvollziehen? Nochmal die Frage: Was funktioniert denn Deiner Meinung nach bei deiner VCCU?
Gruß Otto
Wir müssn hier 2 Dinge trennen bevor es hier noch verwirrender wird.
Ich habe eine lauffähige Konfiguration mit einem HMLAN-Adapter und einer VCCU. Dort ist kein IOList gesetzt. Diese Konfiguration habe ich damals angelegt damit die Taster eine Antwort erhalten. Und hier reagiere ich auf die Events an der VCCU - funktioniert einwandfrei.
Internals:
DEF 2BACDD
IODev HMLAN01
NAME vccu
NOTIFYDEV global
NR 48
NTFY_ORDER 50-vccu
STATE CMDs_done
TYPE CUL_HM
channel_01 vccu_Btn1
channel_02 vccu_Btn2
channel_03 vccu_Btn3
channel_04 vccu_Btn4
channel_05 vccu_Btn5
channel_06 vccu_Btn6
channel_07 vccu_Btn7
channel_08 vccu_Btn8
channel_09 vccu_Btn9
channel_10 vccu_Btn10
protSnd 1 last_at:2018-11-24 09:09:15
protState CMDs_done
READINGS:
2018-11-24 09:09:15 state CMDs_done
helper:
HM_CMDNR 8
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
mRssi:
mNo
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
Attributes:
DbLogExclude .*
IODev HMLAN01
expert 2_full
model virtual_16
room SYSTEM->Cul_HM
subType virtual
webCmd virtual
Jetzt möchte ich ein komplett neues FHEM aufsetzen welches mit dem anderen nichts zu tun hat. Das neue System verwendet einen HM_MOD_RPI_PCB und auch eine VCCU.
Internals:
DEF 6A60AE
HM_MOD_RPI_PCB_MSGCNT 115
HM_MOD_RPI_PCB_RAWMSG 05000022AF8610568F520000000A88C10F0040
HM_MOD_RPI_PCB_RSSI -34
HM_MOD_RPI_PCB_TIME 2018-11-24 15:25:50
IODev HM_MOD_RPI_PCB
LASTInputDev HM_MOD_RPI_PCB
MSGCNT 115
NAME VCCU
NOTIFYDEV global
NR 28
NTFY_ORDER 50-VCCU
STATE HM_MOD_RPI_PCB:ERROR-Overload,
TYPE CUL_HM
assignedIOs HM_MOD_RPI_PCB
channel_01 VCCU_Btn1
protSnd 1 last_at:2018-11-24 14:47:49
protState CMDs_done
READINGS:
2018-11-24 15:01:14 state HM_MOD_RPI_PCB:ERROR-Overload,
2018-11-24 13:27:04 unknown_2D2D0E received
2018-11-24 14:45:39 unknown_305C2E received
2018-11-24 15:24:33 unknown_3C5A11 received
2018-11-24 15:24:35 unknown_51B1F7 received
2018-11-24 15:25:50 unknown_568F52 received
helper:
HM_CMDNR 180
mId FFF0
regLst ,0
rxType 1
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
ioList:
HM_MOD_RPI_PCB
mRssi:
mNo
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
rssi:
shadowReg:
Attributes:
IODev HM_MOD_RPI_PCB
IOList HM_MOD_RPI_PCB
IOgrp VCCU
expert 2_raw
model CCU-FHEM
room SYSTEM->Fhem
subType virtual
webCmd virtual:update
In dem neuen System möchte ich zusätzlich Rauchmelder integrieren. Laut Wiki ist es sinnvoll diese in ein Team zu packen um z.B. auch Funktionstests des gesamten Teams ausführen zu können. Hierfür benötigt man eine eigenen HMId laut Wiki. Wenn ich die gleiche verwenden möchte, meckert FHEM ja auch korrekterweise.
Internals:
DEF 5E71CF
IODev VCCU
NAME SmokeDetectorTeamDev
NOTIFYDEV global
NR 79
NTFY_ORDER 50-SmokeDetectorTeamDev
STATE CMDs_done_Errors:1
TYPE CUL_HM
channel_01 SmokeDetectorTeam
protCmdDel 39
protIOerr 3 last_at:2018-11-24 15:23:49
protSnd 60 last_at:2018-11-24 14:56:51
protSndB 60 last_at:2018-11-24 14:56:51
protState CMDs_done_Errors:1
READINGS:
2018-11-24 15:23:49 state CMDs_done_Errors:1
helper:
HM_CMDNR 214
alarmNo 01
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu VCCU
mRssi:
mNo
io:
HM_MOD_RPI_PCB:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
shadowReg:
Attributes:
IODev VCCU
IOgrp VCCU
expert 2_raw
model virtual_1
subType virtual
webCmd virtual
Die Rauchmelder an sich funktionieren auch alle mit FHEM einwandfrei. Das Einzige was Probleme macht, ist das Peering. 4 von 6 Rauchmelder blinken mittlerweile fleißig wenn ich einen TeamCall ausführe. Mit den anderen 2 bekomme ich kein Peering hin. Wenn ich beispielsweise set SmokeDetectorTeam peerChan 0 SD_PRIVAT_Flur single set actor ausführe und am Rauchmelder anschließend ein getConfig, bekomme ich entweder ein Nack, MissingAck oder IOErr. Bei letzterem sagt mein HM_MOD_RPI_PCB auch was von Overload.
Du verwendest also in deinem alten System die VCCU als virtuellen Channel und nicht als VCCU, kann sein - es geht offenbar. Wäre meiner Meinung nach besser gewesen es entweder richtig (komplett) zu machen oder anstatt der VCCU einen virtuellen Aktor zu verwenden.
In deinem neuen System solltest Du jetzt einfach alles richtig einrichten (zweimal falsch gemacht ergibt nicht zwangsweise richtig :) ) dann etwas Ruhe einkehren lassen (Overload) vielleicht einmal neu starten und versuchen die Meldungen in configCheck durch saubere Wiederholung der Konfigurationsschritte zu beseitigen.
Dann wird auch alles gehen.
Du wirfst bisher scheinbar virtuellen Aktor und VCCU in einen Topf und denkst es ist das Gleiche!?!
Gruß Otto
und schon wieder selbst ausgedachte dinge, die nicht funktionieren.
IODev VCCU
dabei war das IODev vor ein paar Tagen schon mal richtig :o
Zitatund schon wieder selbst ausgedachte dinge, die nicht funktionieren.
Woher willst du denn wissen dass es nicht funktioniert? Es funktioniert sogar sehr gut. Ich kann die Readings auslesen als auch TeamCall und Alarm ein- und ausschalten.
Bitte denkt immer lösungsorientiert und denkt daran jemanden der an einer Stelle nicht weiterkommt und verschiedene Optionen ausprobiert, keine "abwertenden" Anworten zu geben! Jeder kommt mal in so eine Situation dass sein System nicht auf Anhieb läuft und man manchmal den Wald vor lauter Bäumen nicht sieht.
Lieber ToM_ToM,
wenn alles super funktioniert - dann ist doch alles gut oder?
Ich werde Dich jedenfalls nicht weiter nerven. Es ist eigentlich alles gesagt ;D
Schönen Abend
Otto
Zitatwenn alles super funktioniert - dann ist doch alles gut oder?
Hallo Otto,
alles bis auf 2 Rauchmelder die kein korrektes Peering haben. Ich habe das System mit euren Tipps jetzt schon mehrfach neu aufgesetzt, aber es bleibt dabei. Die 2 Rauchmelder wollen nicht.
Vielen Dank nochmal fü eure konstruktiven Antworten zu dem Thema.
VG, Thomas
Nachtrag:
Es scheint tatsächlich dass die 2 Rauchmelder kaputt sind. Ich habe mehrfach das System neu aufgesezt und es sind immer die gleichen 2 Rauchmelder die beim Peering ein NACK als Ergebnis liefern.
Viele Grüße
Thomas