hallo martin,
meine HM-SEC-RHS melden seit dem letzten update nicht mehr grün sondern orange.
das update davor hat sogar nur rot gemeldet.
die frage ist jetzt ob das absicht ist?
die dinger sind jeweils nur mit fhem gepaired und mit nichts gepeered. ich weiß das du immer einen virtuellen aktor zum peeren vorschlägst aber bis jetzt ging es völlig problemlos auch ohne.
gruss
andre
Hi Andre,
muss ich auch noch einmal irgendo vermerken
A) Kommunikation LEDs
- Orange: Device hat etwas gemeldet - die Zentrale hat geantwortet. Es ist nichts gepeert. KEIN Feherl erkannt
- rot: irgendjemand, der sollte hat NICHT geantwortet =>FEHLER erkannt
- gruen: Das Device hat sich ausgetauscht. Wenn es ein trigger war, dann ist es gepeert (min 1-mal) und ALLE peers habe geantwortet. => KEIN Fehler
Zitatdie frage ist jetzt ob das absicht ist?
Rot ist NIE beabsichtigt. Der Rest liegt nicht in meiner Hand.
Zitatich weiß das du immer einen virtuellen aktor zum peeren vorschlägst
ich will immer einen Endpunkt für einen Trigger. Muss man aber nicht machen, bin eben ich.
B) Virtuelle Aktoren
muss man nicht nutzen, machen manche Dinge m.E. übersichtlicher.
C)FHEM Kanäle
man kann alternativ zu virtuellen Kanäle auch Kanäle der "Zentrale" nutzen. So bietet es auch HM in seiner SW an. Es ist auch in FHEM eingebaut. Ist aber nicht ganz einfach/geradlinig. Es liegt an der nicht durchgängigen Struktur, die in FHEM existiert. Viele User haben schon ohne dies Probleme, manche zusammenhänge zu verstehen. Man kann es nutzen, aber für die breite Masse sehe ich Probleme im Detail.
Ich fange einmal an, etwas zu erklären
a) HMLAN und CUL sind IO devices. Dass dort die HMId vergeben wird ist schon das erste Problem
b) die HMId ist NICHT die ID des IODev sondern die einer Zentrale
c) man kann mehrere HMIds nutzen, dann hat man mehrere (virtuelle) HM-Zentralen - so sehen es die HM-devices
d) leider gibt es keine Instanz einer "Zentrale". Das ist nun eine Problem. Eigentlich müsste man eine Zentrale definieren und dieser IO devices zuordnen - und HM devices.
e) jede Zentrale kann bis zu 50 Kanäle haben. Diese kann man als virtuelle Buttons verwenden. Da es aber keine Instanz "HM-CCU" gibt ist die Verwaltung schwierig.
f) Die Kanäle der "zentrale" werden 'fhem01'...'fhem50' genannt. Hier siehst du auch schon das Problem - wenn es mehrere Zentralen gibt müsste der Name 'fhem' unterschieden werden.
g) die Verwaltung der HMId im IODevice ist kritisch. Sie entzieht sich der Überwachung von CUL_HM
f) AES keys müssen an der Zentrale verankert werden, nicht am IO
g) die Übersicht über genutzte "zentralen-channel" ist nur schwer darstellbar - keine Instanz vorhanden. HMInfo unterstützt hier ein wenig.
D) Vorteile von "virtuellen-Zentralen-Buttons"
a) korrektes ACK handling bei HMLAN und CUL (virtuelle Aktoren mogeln hier!)
b) man kann hier AES nutzen - kann sehr wichtig sein!
E) zusammenfassung
Wenn man komplexere und ausgereiftere HM Systeme bauen will (AES wirklich durchziehen, mehr IO devices, mehr Zentralen) werden einem die ganzen Vereinfachungen um die Ohren fliegen.
Vielleicht werde ich einmal ein Zentralen-konzept erstellen.
Das hast du garnicht alles gefragt...
hallo martin,
wozu die farben sind ist klar. das rot nicht beabsichtig war auch.
die frage bezog sich auch orange/grün. das verhalten hat sich definitiv geändert.
vor dem update (seit ich die dinger das erste mal im einsatz habe) haben sie immer grün gemeldet. auch ohne das sie jemals gepeered waren.
nach dem update melden sie orange ohne das sich (ausserhalb von fhem) etwas geändert hat. die frage war also ob diese änderung beabsichtigt war. für alle mitbenutzer (so fern ihnen das geblinke nicht eh ganz egal ist) ist orange nicht intuitiv mit in ordnung gleichzusetzen..
zu den ios/zentralen/hm ids: im prinzip auch klar. leider aber nicht so einfach und nicht immer ohne nebeneffekte. besonders wenn man cul und hmlan mischt und die gleiche id verwendet. das geht von problemen beim pairing wenn man das pairForSec nur für den cul setzt oder mit autoren die beim register setzen spinnen so lange der hmlan gleichzeitig angeklemmt ist. die alternative mehrere hmids zu verwenden hat leider den nachteil des single point of failure wenn dasjenige iodev ausfällt.
hier wäre das konzept einer zentrale die mehrere hmids zusammenfassen und bei ausfall eines iodev auch dynamisch umverteilen kann klasse. d.h. man hätte im normalbetrieb den vorteil die kommunikation auf das 'eigene' nächste iodev zu beschränken und per hmid zu trennen, wenn ein iodev ausfällt könnte man aber trotzdem immer noch alles bedienen.
ich hab das alles nicht gefragt aber das heisst ja nicht das mich die erklärung nicht interessiert :). ganz im gegenteil.es wäre nur schade wenn diese und andere erklärungen in einem thread den bald keiner mehr liest versauern.
das mit den zentralen kanälen schaue ich mir mal an. ich glaube das gefällt mir besser als die virtuellen aktoren und eigentlich vom konzept auch logischer. ich möchte ja das die HM-SEC-RHS an die zentrale melden und dann ist auch das ack von der zentrale das 'richtige'. eine vereinfachung die vielleicht nicht um die ohren fliegt wäre vielleicht ein attribut im device das angibt ob es ein ack von der zentrale geben soll. vielleicht sogar automatisch wenn es keine peers gibt.
gruss
andre
Zitat von: justme1968 am 17 April 2014, 13:13:24
für alle mitbenutzer (so fern ihnen das geblinke nicht eh ganz egal ist) ist orange nicht intuitiv mit in ordnung gleichzusetzen..
An und für sich ist die intuitive Regel ja eine völlig andere: Alles was nicht rot ist, ist "in Ordnung".
das kommt drauf an wie schnell das auto ist :)
Zitatdie frage bezog sich auch orange/grün. das verhalten hat sich definitiv geändert.
War nicht beabsichtigt.
Konnte an der Art des ACK liegen.
Du kannst es gerne mit Zeile 1908 probieren:
# push @ack,$shash,$mNo."8002".$dst.$src."0101".(($recChn&1)?"C8":"00")."00";
push @ack,$shash,$mNo."8002$dst$src"."00";
wieder drehen nach
push @ack,$shash,$mNo."8002".$dst.$src."0101".(($recChn&1)?"C8":"00")."00";
# push @ack,$shash,$mNo."8002$dst$src"."00";
und evtl noch
push @ack,$shash,$mNo."8002".$dst.$src."0101".(($recChn&1)?"00":"C8")."00";
# push @ack,$shash,$mNo."8002".$dst.$src."0101".(($recChn&1)?"C8":"00")."00";
# push @ack,$shash,$mNo."8002$dst$src"."00";
testen.
Dann würde es bedeuten, dass ein ACK (gelb) oder ein ACK-Status (Gruen) empfangen wurde.
Zitatbesonders wenn man cul und hmlan mischt und die gleiche id verwendet.
daher wäre das einzig korrekte setup eine "HM-Central" zu definieren und dieser dann IOs zuzuweisen. Und devices. Umbau ist immer schwierig - aber dann würden m.E. die User auch besser verstehen. Aktuell haben die meisten nur Glück, dass sie eh nichts komplexes nutzen.
Zitatdie alternative mehrere hmids zu verwenden hat leider den nachteil des single point of failure wenn dasjenige iodev ausfällt.
Das könnte der User wie jetzt auch entscheiden. Jeden Zentrale hätte eine beliebige Anzahl IODevs. Ein Device hat eine Zentrale und ein IODev. Die HMSW macht das genauso - nur das man nur eine Zentrale kann. Mehrere Zentralen wären in FHEM möglich... nicht in HM-SW.
Zitathier wäre das konzept einer zentrale die mehrere hmids zusammenfassen und bei ausfall eines iodev auch dynamisch umverteilen kann klasse
das ist so nicht möglich. Man müsste neu pairen.
Die Idee wäre
n Zentralen (kann auch Eins sein) mit je m IODevs. Ein IODev gehört immer zu einer Zentrale, eine Zentrale kann mehrere IOs. Man könnte aber das IODev eines Device gegen ein weiteres der gleichen Zentrale tauschen, wenn eins ausgefallen ist....
p.s.:wäre schon schön, präzise zu wissen, was orange genau bedeuten soll
probiere ich aus.
die idee die iodev dynamisch auch mit einer anderen hmid zu verwenden geht natürlich nur wenn auch die alternativen noch innerhalb der funkreichweite sind. dann sollte es auch ohne neu pairen gehen. das ist unterm strich aber immer noch besser als gar nichts. und ob die reichweite passt könnte man sogar halb automatisch annähern wenn man die rssi werte berücksichtigt.
Zitat von: martinp876 am 17 April 2014, 14:05:56
n Zentralen (kann auch Eins sein) mit je m IODevs. Ein IODev gehört immer zu einer Zentrale, eine Zentrale kann mehrere IOs. Man könnte aber das IODev eines Device gegen ein weiteres der gleichen Zentrale tauschen, wenn eins ausgefallen ist....
Wo ist das Problem?
Ich habe hier zwei Zentralen:
1 * CCU2 (die wir in der Betrachtung mal ausser acht lassen)
1 * fhem
Die Zentrale fhem selbst hat zwei IODev für Homematic:
2 * HMUSBCFG die hier in der Wohnung per Netzwerk verteilt untergebracht sind.
Alle Zentralen UND alle IODev sind mit der
identischen HMID konfiguriert - das funktioniert absolut super.
Ich kann jetzt einen beliebigen HMUSB abziehen und das komplette FHEM läuft absolut fehlerfrei weiter, (solange die HM-Komponenten innerhalb der Funkreichweite des anderen HMUSB liegen)
Eine Zuordnung von IODev zu Komponenten habe ich überhaupt nicht durchgeführt, das funktioniert alles out-of-the-box.
hallo martin,
es lag nicht an deinem code.
aus irgendeinem grund haben die HM-SEC-RHS ihr pairing verloren und an broadcast gesendet.
an allen neu anlernen gedrückt und jetzt bekommen sie wieder grün. wie gehabt. ohne peer und ohne kanäle der zentrale. unabhängig welche der drei zeilen ich verwende...
gruss
andre
Ein Aufbau mit einer CCU (FHEM extern) und FHEM einem eigenen IO ist eine andere Baustelle - die ist hier nicht diskutiert worden. Hier geht es um Ersatzschaltung verschiedener IOs der gleichen Zentrale. FHEM hatte so etwas mit IO-groups angedacht....
Die auch in HM-SW angebotenen Schalter sind noch ein anderes Thema - da wird es dann mit mischen schon schwieriger....
Dein Anwendungsfall funktioniert - deckt aber wirklich nicht alles ab. Und ist eher speziell