Hallo,
ich habe mir eine VCCU nach der Anleitung im Wiki angelegt. Signale kommen an, schalten geht immer noch. Also erstmal nicht all zu verkehrt konfiguriert.
Ich habe einen CUL im Einsatz, ich möchte einen zweiten konfigurieren als Teil meines Failover-Scenarios.
Ausgangssituation
CUL1: /dev/ttyUSB0 initialized
CUL2: /dev/ttyUSB3 disconnected
VCCU: STATE CUL1:OK,CUL2: disconnected - zeigt korrekt die Situation
Mein Test:
CUL1 - Definition wird auf ttyUSB3 geänert (Ausfall simuliert) --> disconnected
CUL2 - Definition wird auf ttyUSB0 geändert (Einstecken des zweiten CUL simuliert) --> initialized
VCCU: STATE CUL1:OK,CUL2: disconnected - falsch, zeigt immer noch die Situation oben an, jedoch würde ich erwarten dass durch Events von den CUL1/2 der Status angepasst wird
--> Events im Eventmonitor bezüglich Statuswechsel beider CUL zu sehen
--> HM Geräte reagieren nicht mehr
VCCU: habe "set update" ausgeführt
--> Status wird nun richtig angezeigt STATE CUL1: disconnected,CUL2: OK
--> HM Geräte reagieren immer noch nicht
FHEM restartet
--> HM Geräte reagieren wieder
Ich hätte gedacht, dass durch das disconnect/initialized-Event die VCCU automatisch auf die geänderte Situation reagiert.
--> Ist mein Verständnis falsch?
--> Kann ich die CUL umstecken, umkonfigurieren ohne dass ich durchstarten muss?
List meiner Devices. Sind auch in der Reichenfolge in der fhem.cfg wegen Reihenfolge des Einlesens.
CUL1
defmod CUL866 CUL /dev/ttyUSB0@38400 1234
attr CUL866 DbLogExclude .*
attr CUL866 group Devices
attr CUL866 hmId F11234
attr CUL866 icon cul_cul
attr CUL866 rfmode HomeMatic
attr CUL866 room Server
setstate CUL866 2019-03-01 20:20:52 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
setstate CUL866 2019-06-07 09:34:17 cmds A B C E e F f G i K l M N R T t U V W X x Z
setstate CUL866 2019-06-07 09:34:17 state Initialized
setstate CUL866 2019-02-19 13:03:22 version V 1.26.01 a-culfw Build: private build (unknown) nanoCUL868 (F-Band: 868MHz)
CUL2
defmod CUL866_2 CUL /dev/ttyUSB3@38400 1122
attr CUL866_2 DbLogExclude .*
attr CUL866_2 group Devices
attr CUL866_2 hmId F11234
attr CUL866_2 icon cul_cul
attr CUL866_2 rfmode HomeMatic
attr CUL866_2 room Server
setstate CUL866_2 disconnected
setstate CUL866_2 2019-06-07 08:35:15 ccconf freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
setstate CUL866_2 2019-06-07 09:12:34 cmds A B C E e F f G i K l M N R T t U V W X x Z
setstate CUL866_2 2019-06-07 09:34:27 state disconnected
VCCU
defmod VCCU CUL_HM F11234
attr VCCU .mId FFF0
attr VCCU DbLogExclude .*
attr VCCU IODev CUL866
attr VCCU IOList CUL866,CUL866_2
attr VCCU IOgrp VCCU
attr VCCU group Devices
attr VCCU model CCU-FHEM
attr VCCU room Server
attr VCCU subType virtual
attr VCCU webCmd virtual:update
setstate VCCU CUL866:ok,CUL866_2:disconnected
setstate VCCU 2019-06-07 09:35:25 IOopen 1
setstate VCCU 2019-06-07 09:35:25 state CUL866:ok,CUL866_2:disconnected
setstate VCCU 2019-06-06 21:24:32 status_HMTempSensor2 0
setstate VCCU 2019-06-06 21:24:32 status_HMTempSensor3 0
setstate VCCU 2019-06-06 21:24:32 status_HMTempSensor4 0
setstate VCCU 2019-06-06 21:24:32 status_Heizung_Schlafzimmer 0
setstate VCCU 2019-06-06 21:24:32 status_Heizung_Wohnzimmer 0
setstate VCCU 2019-06-06 21:24:32 status_hm_door1 0
setstate VCCU 2019-06-07 09:20:16 unknown_5B1656 received
setstate VCCU 2019-06-07 07:24:32 unknown_5B5D2D received
setstate VCCU 2019-06-07 08:21:48 unknown_60045C received
setstate VCCU 2019-06-07 09:32:56 unknown_638F34 received
Türsensor (als Beispiel). Gibt etliche Devices
defmod hm_door1 CUL_HM 6DF1A1
attr hm_door1 .mId 0030
attr hm_door1 IODev CUL866
attr hm_door1 IOgrp VCCU
attr hm_door1 actCycle 168:00
attr hm_door1 actStatus alive
attr hm_door1 autoReadReg 4_reqStatus
attr hm_door1 comment 3,44 V, 03.02.2018
attr hm_door1 event-on-change-reading state,battery,door
attr hm_door1 expert 2_raw
attr hm_door1 firmware 1.8
attr hm_door1 group Tür
attr hm_door1 model HM-SEC-RHS
attr hm_door1 peerIDs 00000000,
attr hm_door1 room Status
attr hm_door1 serialNr HM_DOOR_01
attr hm_door1 subType threeStateSensor
attr hm_door1 userReadings door {ReadingsVal($name,"state","err")}
setstate hm_door1 closed
setstate hm_door1 2018-06-29 17:19:57 .D-devInfo 010100
setstate hm_door1 2018-06-29 17:19:57 .D-stc 80
setstate hm_door1 2018-06-27 20:43:14 .R-ledOnTime 0.5 s
setstate hm_door1 2018-06-27 20:43:14 .R-msgRhsPosA closed
setstate hm_door1 2018-06-27 20:43:14 .R-msgRhsPosB open
setstate hm_door1 2018-06-27 20:43:14 .R-msgRhsPosC tilted
setstate hm_door1 2018-06-27 20:43:13 .R-transmDevTryMax 6
setstate hm_door1 2018-06-27 20:43:14 .R-transmitTryMax 6
setstate hm_door1 2018-06-27 20:43:15 .peerListRDate 2018-06-27 20:43:15
setstate hm_door1 2019-06-07 09:13:17 .protLastRcv 2019-06-07 09:13:17
setstate hm_door1 2019-06-07 09:12:53 Activity alive
setstate hm_door1 2018-06-29 17:19:57 D-firmware 1.8
setstate hm_door1 2018-06-29 17:19:57 D-serialNr HM_DOOR_01
setstate hm_door1 2018-06-27 20:43:13 PairedTo 0x000000
setstate hm_door1 2018-06-27 20:43:13 R-cyclicInfoMsg on
setstate hm_door1 2018-06-27 20:43:14 R-eventDlyTime 0 s
setstate hm_door1 2018-06-27 20:43:13 R-pairCentral 0x000000
setstate hm_door1 2018-06-27 20:43:14 R-sign off
setstate hm_door1 2018-06-27 20:43:13 RegL_00. 02:00 09:01 0A:00 0B:00 0C:00 14:06 10:01 00:00
setstate hm_door1 2018-06-27 20:43:14 RegL_01. 08:00 20:6C 21:00 22:64 30:06 00:00
setstate hm_door1 2018-06-28 20:25:43 alive yes
setstate hm_door1 2019-06-07 09:13:17 battery ok
setstate hm_door1 2019-06-07 09:13:17 contact closed (to broadcast)
setstate hm_door1 2018-06-28 20:25:43 cover closed
setstate hm_door1 2019-06-07 09:13:17 door closed
setstate hm_door1 2018-06-28 20:25:43 powerOn 2018-06-28 20:25:43
setstate hm_door1 2018-06-28 20:25:43 recentStateType info
setstate hm_door1 2019-06-07 09:13:17 state closed
setstate hm_door1 2018-06-29 17:10:55 trigDst_F11234 noConfig
setstate hm_door1 2019-06-07 09:13:17 trigger_cnt 109
Entweder ist Dein Türsensor ein schlechtes Beispiel, oder Du hast da durchgehend noch ein anderes Problem.
Der ist nämlich nicht gepaired (PairedTo 0x000000) und ruft daher nur in die Welt (to broadcast) statt an die VCCU (to VCCU).
Zitat von: Hollo am 11 Juni 2019, 13:05:34
Entweder ist Dein Türsensor ein schlechtes Beispiel, oder Du hast da durchgehend noch ein anderes Problem.
Der ist nämlich nicht gepaired (PairedTo 0x000000) und ruft daher nur in die Welt (to broadcast) statt an die VCCU (to VCCU).
Wahrscheinlich beides. Türsensor hängt da schon seit ewig und sendet zuverlässig. Config könnte ich mal reinitieren damit das Reading gefüllt wird. Anderes Beispiel als list Temperatursensor. Sendet auch nichts mehr nachdem ich CUL1 und CUL2 getauscht habe ... keines der HM-Geräte. Erst wieder wenn ich reboote. HM-Config-Check bringt nur den Fehler, dass hmdoor kein HMID hat und noch Missmatch der Temperaturtemplates bei den Thermostaten.
Für mich zum Verständnis, sollte VCCU automatisch erkennen wenn ein CUL ausfällt? Aktuell muss ich set update machen damit der Wechsel erkannt wird. Dann ist zumindest state richtig. Aber dennoch funktioniert erst nach dem Reboot das re-routing. Ich möchte es verstehen. Der zweite CUL kommt sowieso an das Failover System und somit habe ich einen Reboot.
Internals:
CUL866_2_MSGCNT 554
CUL866_2_RAWMSG A145E8470003112F1123400F304003E000000080ECC::-70:CUL866_2
CUL866_2_RSSI -70
CUL866_2_TIME 2019-06-11 15:38:37
DEF 003112
FUUID 5c575e1f-f33f-4fe4-9116-a2c8852e790574c2
IODev CUL866
LASTInputDev CUL866_2
MSGCNT 554
NAME HMTempSensor4
NOTIFYDEV global
NR 575
NTFY_ORDER 50-HMTempSensor4
STATE T: 24.3 H: 62 B: 8.0
TYPE CUL_HM
chanNo 01
lastMsg No:5E - t:70 s:003112 d:F11234 00F304003E000000080ECC
protLastRcv 2019-06-11 15:38:37
protRcv 554 last_at:2019-06-11 15:38:37
rssi_at_CUL866_2 cnt:554 min:-76 max:-68 avg:-70.64 lst:-70
Helper:
DBLOG:
batVoltage:
myDbLog:
TIME 1560259645.27044
VALUE 3.79
brightness:
myDbLog:
TIME 1560260317.77645
VALUE 8.0
humidity:
myDbLog:
TIME 1560261113.88621
VALUE 62
temperature:
myDbLog:
TIME 1560261113.88794
VALUE 24.3
READINGS:
2019-06-11 15:33:01 1 13.7
2019-06-09 11:52:08 Activity alive
2018-07-07 08:26:42 CommandAccepted yes
2018-07-07 08:28:02 D-firmware 1.0
2018-07-07 08:28:02 D-serialNr THLSHT3112
2018-07-07 08:27:48 PairedTo 0xF11234
2018-07-07 08:27:47 R-pairCentral 0xF11234
2018-07-07 08:27:48 RegL_00. 0A:F1 0B:12 0C:34 14:06 12:24 20:01 21:2C 22:00 23:00 00:00
2019-06-11 15:38:37 batVoltage 3.79
2019-06-11 15:38:37 battery ok
2019-06-11 15:38:37 brightness 8.0
2019-06-11 15:38:37 calcHumOut 74
2019-06-11 15:33:01 dewpoint 16.6
2019-06-11 15:38:37 humidity 62
2018-07-07 08:27:55 recentStateType info
2019-06-11 15:38:37 state T: 24.3 H: 62 B: 8.0
2019-06-11 15:38:37 temperature 24.3
helper:
HM_CMDNR 94
mId F103
peerFriend peerRecT
peerOpt p:THPLSensor
regLst 0
rxType 156
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +003112,00,00,00
nextSend 1560260317.86908
prefIO
rxt 2
vccu VCCU
p:
003112
00
00
00
mRssi:
mNo 5E
io:
CUL866_2:
-70
-70
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat 00
role:
chn 1
dev 1
rssi:
at_CUL866_2:
avg -70.6407942238267
cnt 554
lst -70
max -68
min -76
tmpl:
Attributes:
IODev CUL866
IOgrp VCCU
actCycle 006:00
actStatus alive
alias Wohnzimmer
autoReadReg 4_reqStatus
event-min-interval humidity:1800,temperature:1800,pressure:1800,pressure-nn:1800,batVoltage:7200,brightness:1800
event-on-change-reading humidity,temperature,battery,batVoltage,pressure,pressure-nn,brightness
expert 2_raw
firmware 1.0
genericDeviceType thermometer
group Wohnzimmer
homebridgeMapping CurrentTemperature=20,nocache=1
icon temperature_humidity
model HB-UNI-Sensor1
peerIDs 00000000,
serialNr THLSHT3112
subType THPLSensor
userReadings calcHumOut { shiftRelHumidity(ReadingsVal("HMTempSensor2","temperature","0"),ReadingsVal("HMTempSensor2","humidity","0"),ReadingsVal($name,"temperature","0"))}
Moin,
warum willst du denn unbedingt ein Failover (der zweite CUL wird erst aktiviert, wenn der erste ausfällt)?
Mit einer VCCU betreibt man eigentlich mehrere IOs gleichzeitig, zumindest ist das mein Verständnis bisher. Ich habe bspw. über zwei hmland Services zwei HM-CFG-USB-2 (jeweils mit einer 5m USB Verlängerung) an- und eingebunden.
Warum sollte ich nur einen benutzen, wenn ich zwei HM-USB (in deinem Fall zwei CULs) habe?
Falls mal einer ausfällt, hast du ja immer noch einen in Betrieb.
Oder verstehe ich dich falsch?
Viele Grüße Hoppel
Hi,
was Du beschreibst, ist m.M. nach irrelevant. Du betreibst Sensoren, teilweise nicht mal gepairt. Für den Empfang ist die VCCU und der eingetragene IO schnurz. Mithören (empfangen) können alle IOs.
Bei einer Steuerung würde die VCCU umschalten, Deine Beispiele sind ohne Steuerung.
Ich sehe auch keinen zweiten IO, Du schaltest nur einen IO per Def um. Ich weiß nicht ob man das so simulieren kann. Ich weiß nicht, ob ein CUL nach der Umdefinition ohne Reboot wirklich läuft
Oder was meinst Du mit HM Geräte reagieren nicht? Und was meinst Du mit rerouting?
Und noch ein Tipp: Nimm/plane ordentliche IOs von Homematic und keine CULs
Gruß Otto
Zitat von: hoppel118 am 11 Juni 2019, 22:10:23
warum willst du denn unbedingt ein Failover (der zweite CUL wird erst aktiviert, wenn der erste ausfällt)?
Warum sollte ich nur einen benutzen, wenn ich zwei HM-USB (in deinem Fall zwei CULs) habe?
mir gehts um ein System-Failover. Habe meine Installation in einer Vm gespiegelt (rsync). Ich bin oft unterwegs, und mir ist mal durch ein kurzen Stromausfall mein Rechner halb hängen geblieben. Sonderfall, aber dennoch möglich. In dem Fall kann ich (und hab ich) die Kopie in der VM einfach hochfahren. Mir fehlte aber HM. Ich hänge nun einen CUL an den Fhem-Host und einen an den PC mit VMWare. In der Konfiguration sind beide CUL in der VCCU definiert. Die VCCU findet immer einen CUL egal ob Fhem-Host oder VM.
Zitat von: Otto123 am 11 Juni 2019, 22:21:59
was Du beschreibst, ist m.M. nach irrelevant. Du betreibst Sensoren, teilweise nicht mal gepairt.
Richtig, ein einziges von vielen Devices ist nicht gepaired
Zitat von: Otto123 am 11 Juni 2019, 22:21:59
Ich sehe auch keinen zweiten IO, Du schaltest nur einen IO per Def um. Ich weiß nicht ob man das so simulieren kann. Ich weiß nicht, ob ein CUL nach der Umdefinition ohne Reboot wirklich läuft
Mag sein, hab angenommen dass man umschalten kann. Ich baue mir Wochenende oder zeitnah einen zweiten CUL dann kann ich mal durch abstecken testen. Dennoch zeigen die CUL bei der Simulation korrekt initialized bzw. disconnected an. VCCU übernimmt den Status erst durch manuelles "set xxx update".
Zitat von: Otto123 am 11 Juni 2019, 22:21:59
Oder was meinst Du mit HM Geräte reagieren nicht? Und was meinst Du mit rerouting?
Fhem zeigt keine Events mehr von den ganzen HM Sensoren oder Devices. Auch nicht von den korrekt gepairten.
Zitat von: Otto123 am 11 Juni 2019, 22:21:59
Und noch ein Tipp: Nimm/plane ordentliche IOs von Homematic und keine CULs
Kenne die Empfehlung, bleibe aber erstmal beim CUL. Ich war einer der ersten Nutzer die einen nanoCul gebaut haben und läuft seitdem problemlos.
Obwohl es vielleicht irrelevant ist würde ich gerne wissen ...
Sollte die VCCU auf Änderungen automatisch reagieren (in state korrekte Anzeige von CUL initialized / disconnected), oder muss ein "set xxx update" durchgeführt werden? Wird ggf. state nur nicht korrekt angezeigt aber funktioniert dennoch korrekt?
Du solltest den Satz vom Otto123 nicht ignorieren
Die VCCU ist nur für das Senden zuständig
Empfangen und verteilen von HM Nachrichten macht Fhem, nicht die VCCU
Zitat von: kadettilac89 am 11 Juni 2019, 23:09:39
In dem Fall kann ich (und hab ich) die Kopie in der VM einfach hochfahren. Mir fehlte aber HM. Ich hänge nun einen CUL an den Fhem-Host und einen an den PC mit VMWare. In der Konfiguration sind beide CUL in der VCCU definiert. Die VCCU findet immer einen CUL egal ob Fhem-Host oder VM.
Dann brauchst du aber doch den Failover der vccu gar nicht, wenn du fhem entweder auf dem fhem-Host ODER der VM laufen lässt...
...bzw. WO ist denn die vccu definiert bzw. WO läuft sie!?
Wenn du tatsächlich bei Ausfall des "Haupt-Hosts" (fhem-Host) die VM mit ebenfalls fhem-Installation!? hochfährst, dann kannst du doch in der fhem-Host vccu den einen CUL und in der VM-fhem vccu den anderen definieren...
Wichtig ist ja nur, dass beide Installationen dieselbe HMID haben ("Kennung der Zentrale") und besser nicht gleichzeitig laufen bzw. steuern, sonst kommen die Aktoren evtl. "durcheinander": 2 Herren dienen ;)
EDIT: ok, du willst/hast (verständlicherweise) keine 2 unterschiedlichen Konfigurationen...
Anmerkung: hatte auch lange einen CUL, dann den mit der Timing-FW aber letztendlich zu einem echten HM-IO gewechselt. Lief alles wunderbar aber dann kam mein Klingelsensor "um die Ecke" und: nix ging mehr (also nur mit der Timing-FW)...
Gruß, Joachim
Zitat von: MadMax-FHEM am 11 Juni 2019, 23:50:56
EDIT: ok, du willst/hast (verständlicherweise) keine 2 unterschiedlichen Konfigurationen...
genau, nur eine Konfiguration. Wenn ich eine Warnung bekomme, dass FHEM nicht reagiert, möchte ich mich nur meine PC mit VM hochfahren und sonst nichts mehr. Keine Re-Konfiguration.
Es kann ja sein, dass es, wie auch Otto123 schon sagte, daran liegt dass der CUL für meine Simulation einen Reboot benötigt. Habe mir sowieso die Teile für einen zweiten CUL bestellt.
Was mich aber stutzig macht und m. E. nichts mit der Simulation zu tun hat, ist dass state vom VCCU nicht automatisch umspringt. Erst wenn ich ein manuelles "set VCCU update" mache. Ich habe diese Frage hier gestellt da ich nicht bei einem erneuten Ausfall eine kalte Wohnung haben will (Wohnung wird kaum geheizt wenn ich länger unterwegs bin).
Ich teste es mit einem zweiten CUL und wenn es damit nicht so funktioniert wie gedacht melde ich mich nochmal. Solange erstmal danke für die Antworten.
Ich habe eine VCCU mit 3 IOs, 1x HMLAN, 1x lokale HMUART, 1x remote HMUART
Gerade ausprobiert: HMLAN auf close gesetzt, er wechselt seinen Status auf disconnected.
Im gleichen Augenblick wechselt die VCCU ihren Status ebenfalls: STATE HMLAN1:disconnected,HMUART1:ok,ser2netUart:ok
Zitat von: kadettilac89 am 11 Juni 2019, 23:09:39
VCCU übernimmt den Status erst durch manuelles "set xxx update".
Fhem zeigt keine Events mehr von den ganzen HM Sensoren oder Devices. Auch nicht von den korrekt gepairten.
Obwohl es vielleicht irrelevant ist würde ich gerne wissen ...
Sollte die VCCU auf Änderungen automatisch reagieren (in state korrekte Anzeige von CUL initialized / disconnected), oder muss ein "set xxx update" durchgeführt werden? Wird ggf. state nur nicht korrekt angezeigt aber funktioniert dennoch korrekt?
Wie gesagt, ob die Sensoren gepairt sind oder nicht spielt für das Empfangen der Daten keine Rolle. Die VCCU spielt für das Empfangen der Daten auch keine Rolle. Wenn also bei Dir nach der Umdefinition keine Werte mehr reinkommen kann es nur am CUL liegen.
Ja, bei mir reagiert die VCCU automatisch auf die Änderung am IO. Das ist keineswegs irrelevant ;)
Selbst wenn Du jetzt vermutest nur der state wird bei Dir falsch angezeigt: Es funktioniert ja nicht korrekt: Du bekommst keine Werte mehr. ::)
Gruß Otto
Zitat von: kadettilac89 am 12 Juni 2019, 07:04:31
genau, nur eine Konfiguration. Wenn ich eine Warnung bekomme, dass FHEM nicht reagiert, möchte ich mich nur meine PC mit VM hochfahren und sonst nichts mehr. Keine Re-Konfiguration...
Das kann man machen, ABER sinnvoller ist meist die (unbequeme und manchmal aufwändige) Suche nach der Ursache.
Warum reagiert Dein FHEM denn manchmal nicht?
Zurück zum Thema:
- 2 getrennte "identische" Systeme inkl. CUL (ein manuelles Runter-/Hochfahren mit Umstecken ist kein Failover)
- 2 getrennte Systeme, die auf die identische Hardware zugreifen können (nicht gleichzeitig)
Zweites könnte ich z.B. bei HM, da ich 2 HMLAN benutze. Dann musst Du weder umstecken, noch umkonfigurieren, UND hast in der VCCU immer beide IO-Devices aktiv.
In meiner VCCU aktualisiert sich auch der state der einzelnen Devices automatisch korrekt; der beschriebene Effekt ist mir da noch nicht aufgefallen.
Das könnte aber auch daran liegen, dass Du das bisher nur mit 1 Device probierst.
Gerade bei USB-Devices hat sich IMHO auch die "Anschluss-Definition" mittels .../dev/by-id/ als praktikabler und sicherer erwiesen; dann ist es Wurscht an welchem Port Du das Dingen anstöpselst.
Zitat von: kadettilac89 am 12 Juni 2019, 07:04:31
Ich habe diese Frage hier gestellt da ich nicht bei einem erneuten Ausfall eine kalte Wohnung haben will (Wohnung wird kaum geheizt wenn ich länger unterwegs bin).
Wenn du OHNE fhem eine kalte Wohnung hast (und HM), dann machst du aber generell etwas falsch/nicht optimal...
Bei mir läuft die Heizung komplett autark, also OHNE fhem: HM-Komponenten untereinander (mit Wochenprogramm)
fhem plottet bei mir nur Werte (zur Auswertung/weiteren Optimierung) und sorgt für noch mehr Komfort:
- richtig Lüften (kein Problem, wenn eh keiner da ist/wäre ;) )
- Umschaltung zwischen verschiedenen Heizprofilen (auch kein Problem, wenn keiner da ist: läuft es halt mit dem "Standardprogramm")
Gruß, Joachim
Zitat von: Otto123 am 12 Juni 2019, 09:24:14
Wie gesagt, ob die Sensoren gepairt sind oder nicht spielt für das Empfangen der Daten keine Rolle. Die VCCU spielt für das Empfangen der Daten auch keine Rolle. Wenn also bei Dir nach der Umdefinition keine Werte mehr reinkommen kann es nur am CUL liegen.
moment mal...
messages von nicht gepairten geräten (nachbar) werden ja von der vccu aussortiert. dann sollten diese devices aber auch in den "unknown-readings" der vccu sichtbar sein.
edit:
jetzt bin ich unsicher, ob wirklich aussortiert wird, da ja manche ungepairte devices haben, die ihren status melden. allerdings fraglich, ob die dann auch eine vccu haben.
müsste man wohl mal genauer testen.
Zitat von: Otto123 am 12 Juni 2019, 09:24:14
Ich habe eine VCCU mit 3 IOs, 1x HMLAN, 1x lokale HMUART, 1x remote HMUART
Gerade ausprobiert: HMLAN auf close gesetzt, er wechselt seinen Status auf disconnected.
Im gleichen Augenblick wechselt die VCCU ihren Status ebenfalls: STATE HMLAN1:disconnected,HMUART1:ok,ser2netUart:ok
Danke fürs testen. Werde mir das mit einem zweite CUL mal in "echt" ansehen.
Zitat von: Hollo am 12 Juni 2019, 09:25:26
Das kann man machen, ABER sinnvoller ist meist die (unbequeme und manchmal aufwändige) Suche nach der Ursache.
Warum reagiert Dein FHEM denn manchmal nicht?
Ursache ist bekannt, Stromausfall vermutlich nur einen Bruchteil einer Sekunde. Rechner hatte vermutlich noch etwas Strom gepuffert und hing, sollte nicht ist aber passiert. Könnte man natürlich mit USV o. ä. abfangen.
Zitat von: Hollo am 12 Juni 2019, 09:25:26
- 2 getrennte "identische" Systeme inkl. CUL (ein manuelles Runter-/Hochfahren mit Umstecken ist kein Failover)
- 2 getrennte Systeme, die auf die identische Hardware zugreifen können (nicht gleichzeitig)
Failover, ...sind jetzt Begrifflichkeiten. Was ich habe bzw. möchte ich ein Cold Standby. Ich stecke keine Hardware um. Ich habe 2 Server, einer läuft, einer nicht. Im Fehlerfall nach einem Monitoringalert starte ich Server2 remote der auch einen CUL hat. Statt VCCU könnte ich auch einen CH340 Chip nehmen, der hätte an jedem Server selbe ID. Jedoch will ich eindeutige ID haben (FT232).
Auch dir, danke fürs testen
Zitat von: MadMax-FHEM am 12 Juni 2019, 09:35:34
Wenn du OHNE fhem eine kalte Wohnung hast (und HM), dann machst du aber generell etwas falsch/nicht optimal...
Bei mir läuft die Heizung komplett autark, also OHNE fhem: HM-Komponenten untereinander (mit Wochenprogramm)
Das läuft schon richtig. Temperaturlisten im Wochenprogramm sind hinterlegt. Jedoch ist die Wohnung nicht bzw. kaum beheizt wenn ich 2 oder mehr Wochen weg bin. In dem FAll ist das Wochenprogramm Montag bis Sonntag = 15Grad. Wenn ich aber früher als geplant Heim komme, schalte ich von unterwegs das Heizprogramm (Wochenprofil) manuell um. Diesen Komfort hatte ich einmal nicht weil der Server hing. Für längere Programme wie "schalte in 2 Wochen auf Heizprogramm -zu Hause- könnte ich auch eine CCU2 (heißt die Zentrale so?) kaufen. Das will ich mir aber sparen.
Meine Frage nach dem STatusverhalten wurde durch euch beantwortet, werde es selbst mit mehreren Devices nachtesten und ggf. nochmal nachfragen. Setup und Hardware an sich ist eine Designangelegenheit. Bin mir den Einschränkungen und auch manchen Alternativen bewusst.
Zitat von: frank am 12 Juni 2019, 09:55:27
moment mal...
messages von nicht gepairten geräten (nachbar) werden ja von der vccu aussortiert. dann sollten diese devices aber auch in den "unknown-readings" der vccu sichtbar sein.
edit:
jetzt bin ich unsicher, ob wirklich aussortiert wird, da ja manche ungepairte devices haben, die ihren status melden. allerdings fraglich, ob die dann auch eine vccu haben.
müsste man wohl mal genauer testen.
Das der eine Sensor nicht gepairt ist habe ich erst jetzt gesehen, hat jetzt ein Jahr funktioniert, auch mit VCCU meldet er. Test ist hier unnötig, werde den sauber pairen und das passt.
@frank: Wenn der Sensor angelegt ist (nicht gepairt) dann werden doch alle Nachrichten in ihm "verarbeitet". Die VCCU würde doch nur die Hilferufe aussortieren.
@kadettilac89 Wir wollen nicht darauf rumreiten ob der Sensor jetzt gepairt ist oder nicht. Für die Anzeige ist das nicht/kaum relevant. Wichtiger ist eigentlich zu wissen: was genau beeinflusst denn die VCCU, was ändert sich im System durch eine VCCU.
Leider ist auch nur im Wiki relativ lose beschrieben was sie tut und beeinflusst. Dabei ist mir jetzt der Satz aufgefallen:
Ein HMLAN/USB ist etwas enger verbunden als CUL IOs. Keine Ahnung was das bedeutet. ::)
Ich bin gespannt was rauskommt bei deinem Test mit zwei CULs. ;)
Zitat von: Otto123 am 12 Juni 2019, 10:36:13
Ich bin gespannt was rauskommt bei deinem Test mit zwei CULs. ;)
Ich teste es demnächst mal und poste. Vielleicht ist es ja so, dass der CUL etwas anders reagiert (bezogen auf Satz: in HMLAN/USB ist etwas enger verbunden als CUL IOs).
Zitat von: kadettilac89 am 12 Juni 2019, 10:17:00
Failover, ...sind jetzt Begrifflichkeiten. Was ich habe bzw. möchte ich ein Cold Standby. Ich stecke keine Hardware um. Ich habe 2 Server, einer läuft, einer nicht. Im Fehlerfall nach einem Monitoringalert starte ich Server2 remote der auch einen CUL hat. Statt VCCU könnte ich auch einen CH340 Chip nehmen, der hätte an jedem Server selbe ID. Jedoch will ich eindeutige ID haben (FT232).
Es gibt immer unterschiedliche Lösungsansätze und meist liegt der eingeschlagene oder favorisierte Weg auch weniger am Wollen, sondern mehr an äußeren Umständen wie vorhandenen Gerätschaften und/oder dem zur Verfügung stehenden Budget.
Daher ist das auch überhaupt keine Kritik; es sollen ja viel mehr Anregungen und Vor-/Nachteile aufgezeigt werden.
Ich habe die letzten 10 Jahre immer ein quasi identisches System für meinen Linux-Server parat gehabt; hätte so Teile oder alles tauschen können.
Gebraucht habe ich es nie, aber so habe ich mir damals viele Gedanken über die verschiedenen Möglichkeiten gemacht.
Daher (und wegen der Erfahrungen mit einigen USB-Devices) favorisiere ich mittlerweile (W)LAN-Devices.
Damit hat man halt die Möglichkeit, das System "davor" mit wenig Aufwand redundant zu machen; so wie Dein System plus der VM.
Zitat von: Hollo am 12 Juni 2019, 13:03:49
Daher ist das auch überhaupt keine Kritik; es sollen ja viel mehr Anregungen und Vor-/Nachteile aufgezeigt werden.
Ist schon OK. Server, Virtualisierung, Netzwerk, Failover, Security ... mache ich beruflich. Da ist sowas auch mal Spielerei um Themen selber mal auszuprobieren statt nur in Büchern zu lesen. Für Fhem ist es sicher mit Kanonen auf Spatzen oder so, aber es laufen noch anderen Container mit drauf die ich redundant haben will. Habe auch Wlan und andere Protokolle, aber für Heizung ist HM gesetzt wegen Profilen und autarkem arbeiten ...
Zitat von: kadettilac89 am 12 Juni 2019, 10:45:34
Ich teste es demnächst mal und poste. Vielleicht ist es ja so, dass der CUL etwas anders reagiert (bezogen auf Satz: in HMLAN/USB ist etwas enger verbunden als CUL IOs).
So,
- wenn ich 2 Cul an FHEM habe und einen abstecke bleibt der Status in der VCCU "CUL1: OK, CUL2: OK" obwohl einer der CUL auf disconnected geht. Mit beiden CUL getestet ...
* Event "CUL disconnect" ist im Eventlog
* Wenn ich auf "update" klicke wird der Status korrigiert
* Wenn ich FHEM restarte wird der Status korrigiert
- Pakete werden aber über den noch aktiven CUL geschickt. VCCU Konzept funktioniert
Für mich ist es wichtig, dass es mit einem aktiven CUL funktioniert, ob nun der Status in VCCU richtig oder falsch angezeigt wird ist für mich nicht von Bedeutung.
Die Statusanzeige wird nur beim Abstecken im laufenden Betrieb nicht aktualisiert. Das ist sowieso für mein Vorhaben kein Anwendungsfall.
Der Status der vccu bei CUL ist nicht aktuell - bei HMlan schon. werde ich korrigieren.
Bei HMLAN ist es einfacher, da ein HMLAN die VCCU informiert. Bei der ccu habe ich keinen Zugriff auf den Code. Lässt sich aber machen.
Operationell ist das m.E. kein Problem. das wird nicht über den Status der VCCU geprüft, sondern direkt vom IO. Also im Detail:
- will ein Device senden wird geprüft, ob ein Senden schon aktiv ist.
+ Das IO device wird nicht geändert, wenn aktuell der Kommandstack abgearbeitet wird. Dies stellt die notwendige Timing kalkulation sicher
+ ist für dies Device aktuell kein senden am Laufen wird geprüft ob das IO in Betrieb ist und genutzt werden kann. Es wird also das passende (hoffentlich) IO gewählt.
+ Nachteil (dem Timing geschuldet) ist, dass das Senden scheitert, wenn das IO im Laufe des Sendens "verstirbt"
Den Update der CUL-states in den vccu state habe ich gescheut weil es möglicherweise zu erhöhter CPU Last führt.
Zitat von: martinp876 am 16 Juni 2019, 11:25:38
Den Update der CUL-states in den vccu state habe ich gescheut weil es möglicherweise zu erhöhter CPU Last führt.
Hi Martinp876, wie es schein bin ich der erste dem es auffällt, und für mein Setup ist es nicht wichtig den Status zu haben. Bevor ich was umbaue schaue ich mir die Doku an und teste .. dadurch ist der Einstiegspost entstanden.
Wenn es zu CPU-Last oder anderen unerwünschten Effekten kommen kann, wäre eine Alternative das ganze in der Commandref und ggf. im Wiki als Einschränkung zu dokumentieren. Wer will kann sich per Notify ein Update einbauen.
Deine Erläuterung reicht mir weil es das Verhalten erklärt. Ich brauche keine Korrektur :)
Danke dir