Association Erklärung gewünscht

Begonnen von walterschmitz, 26 November 2017, 19:21:22

Vorheriges Thema - Nächstes Thema

walterschmitz

Hallo,

habe gerade das Problem, das mein WT, welches ich Werksresettet habe und anschließend gepaired (mit FHEM) wurde (problemlos), kein Associate annimmt.

Anscheinend kommt kein ACK.

Am WT leuchtet die Antennen-Symbole dauerhaft.
am HT ebenfalls.

HT associated WT lief problemlos durch
WT associated HT blieb das ACK aus.
Credits waren für 3 Versuche vorhanden (man verbraucht 107 bei einem Versuch, es wird automatisch 3x der Versuch geschickt!)

Wenn ich am Gerät (WT) eine Temperatur einstelle, überträgt er das meist an das HT.
Umgekehrt leider nicht. Im besten Fall überschreibt WT später meine händische Einstellung am HT mit den Einstellungen aus dem WT.

Jetzt meine Frage:

1.) Wie funktioniert es nach dem Associate: Sende WT an FHEM und FHEM an HT oder wird das direkt geschickt und FHEM hört nur den Funk ab.
2.) ist ein Pairing untereinander der Geräte noch durchzuführen, damit das sauber läuft oder reicht das associate via FHEM aus (sprich: die Geräte sind im FHEM und in real gepaired bzw. associated)

Anfragen von FHEM an die Devices kann ich gerade aufgrund zu geringer Credits nicht ausprobieren... muss ich später nachliefern.

Ich versteh so langsam die Logik dahinter nicht mehr... Und das alles nur, weil ein Device mal Probleme (von allen) gemacht hat und ich dann alle zurücksetzen musste, um den Fehler zu finden bzw. auszumerzen :-(

Wer kann mir zum Associate kurz Auskunft geben?

Danke im voraus

willyk

Hi,

Zitat von: walterschmitz am 26 November 2017, 19:21:22
1.) Wie funktioniert es nach dem Associate: Sende WT an FHEM und FHEM an HT oder wird das direkt geschickt und FHEM hört nur den Funk ab.
Letzteres. Überleg mal: die Geräte funktionieren eigentlich ohne FHEM. Also müssen die beiden miteinander bekannt sein, damit sie miteinander reden können. Also associate HT -> WT und WT -> HT.
Zitat von: walterschmitz am 26 November 2017, 19:21:22
2.) ist ein Pairing untereinander der Geräte noch durchzuführen, damit das sauber läuft oder reicht das associate via FHEM aus (sprich: die Geräte sind im FHEM und in real gepaired bzw. associated)
Ich bin jetzt mal kleinlich: mit FHEM wird nichts gepaired oder associated. Die Geräte werden mit einem CUL oder Cube gepaired. Der Unterschied ist dann wichtig, wenn du meherer CULs / Cubes in deinem System hast.

Wie gesagt: pairing der Geräte, die miteinander reden sollen.

Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

walterschmitz

Hallo,

also das Associate via FHEM führt dazu, dass es gleichbedeutend zu sehen ist, wie ein Pairing an den beiden Devices direkt, wenn ich das richtig verstehe.

und okay: ich paire bzw. associate mit dem CUL... da hast du Recht!

Lt. FHEM Log gab es im Anschluss an das Pairing bzw. das Associate keine Fehlermeldungen in direktem Bezug (keine nachfolgenden Log-Einträge deuteten auf Fehler hin). Daher gehe ich davon aus, dass sowohl das Pairing als auch das Associate funktioniert hat.
An den Devices leuchtet auch konstant das Antennensymbol, was für mich ein weiteres Indiz darstellt...

Was ich aber trotzdem nicht versteh:
Ich kann die Einstellungen ja jetzt auf unterschiedlichen Wegen vornehmen, eine Temperatur einzustellen.

1.) Einstellung via FHEM:
Ich kann dem WT (via FHEM) eine Temperatur anweisen, die am WT auch zeitnah angezeigt wird. Warum verzögert es sich, bis das HT die Anweisung erhält?
Es müsste doch jetzt so sein, dass ich mit der Eingabe via FHEM die gewünschte Temperatur an das WT übergebe... Wäre das gleichbedeutend mit der direkten Eingabe am WT?

Wenn ja: Warum unterscheidet es sich zeitlich bis die Eingabe am entsprechenden HT ankommt? bei Eingabe am FHEM -> WT -> HT dauert die Umsetzung deutlich länger als wenn ich (direkt) WT -> HT beobachte (jeweils die Zeit betrachtet zwischen Anzeige am WT und später am HT). Hierbei müsste doch gar keine 1%-Regelung eingehalten werden, was evtl. eine Verzögerung erklären könnte, da das WT zuvor nur gehört hat und anschließend erstmalig senden muss, um den Wert weiterzugeben. Würde FHEM den Wert an HT auch übergeben, würde sich der Verzug erklären.

2.) Einstellung direkt am WT:
Hier kann ich etwas einstellen und es wird zeitlich (deutlich) schneller an das HT übertragen.

3.) Einstellung direkt am HT:
Hier entsteht ein Problem, was für mich nicht nachvollziehbar ist:
Ich kann an dem HT KEINE Eingabe machen, die am WT angenommen / angezeigt wird. Sprich, jemand verändert (egal ob via FHEM oder direkt am HT) die Temperatur am HT. Durch das Associate müsste es eigentlich so sein, dass am WT kurze Zeit später die Temperatur (sofern die eingestellte Temperatur auch angezeigt werden soll) angezeigt wird. Leider funktioniert es in dieser Richtung nicht. Wenn ich ein beide Richtungen (also WT->HT UND HT->WT associatet habe) sollte es doch egal sein, ob es ich an dem einen oder anderen Device eine Einstellung vornehme, oder etwa doch nicht?
Log-Eintragungen erscheinen mir auch nicht auffällig. Meist überträgt nach kurzer Zeit das WT erneut die Wunschtemperatur und überschreibt damit die zuvor getätigte Eingabe am HT (Es wird so als sei WT mächtiger als HT - wenn man das mal so formulieren kann). Ist das so gewünscht oder ergibt sich hier eine zufällige "Überschreibung" des Wertes am HT?

Alles in allem kann ich feststellen, dass bei Auslösen wie FHEM alles langsamer abläuft und übertragen wird als wenn man direkt an den Geräten Einstellungen vornimmt :-(

Ist soweit das Verständnis richtig bzw. die Feststellungen so wie sie sein sollen oder vermutet ihr immer noch einen Fehler im System? Ich habe ja neu aufgesetzt... daher versuche ich auch Ursachen bzw. Feststellungen entsprechend nachzuvollziehen.

Kannst du mir bestimmt aber richtig erklären, was wie gewollt ist, denke ich.

Gruß

willyk

Hallo,
Zitat von: walterschmitz am 28 November 2017, 00:49:27
Ich kann an dem HT KEINE Eingabe machen, die am WT angenommen / angezeigt wird.
Wie immer gibt es mehrere Möglichkeiten:
- kein Pairing HT -> WT
- ein Gerät defekt (vermutlich HT kaputt)
- Batterieproblem (führt immer wieder zu interessanten Effekten)

Du hast nicht zufällig noch einen HT, den du tauschen kannst (z.B. aus einem anderen Raum)? Dann könnte man sehen ob das Problem "mitwandert".

Gruss willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

walterschmitz

Okay.

Also mein Verständnis... ich habe gepaired bzw. associated = Eingabe am HT wird kurz später am WT angezeigt ist also richtig.
Von daher HT defekt schließe ich aus, da das Phänomen an allen HT so geschieht.

Das Associate wurde ja auch im Log / EventMonitor bestätigt... von daher fällt das auch weg

Batterie-Problem: Ja kenne ich, aber wie sollte ich das eingrenzen. Da keine Meldungen kommen, Batterie Low ist das auch schwer eingrenzbar.
Ich teste mal weiter und schaue ob ich ein System herausfinden kann.

Aber... kannst du mir für's Verständnis auch das mit dem zeitlichen Verzug erläutern?
Eingabe via FHEM an WT und darüber dann verzögert an das HT vs. direkte Eingabe am WT und direkte Weitergabe am HT.
Für mich ist die Verzögerung nicht nachvollziehbar, da ja nur der Befehl an das WT geht. Warum sendet WT dann nicht direkt weiter.

Trotzdem vielen Dank erst einmal.

Gruß

willyk

Zitat von: walterschmitz am 28 November 2017, 23:28:42
Batterie-Problem: Ja kenne ich, aber wie sollte ich das eingrenzen. Da keine Meldungen kommen, Batterie Low ist das auch schwer eingrenzbar.

Vielleicht ist "battery low" noch nicht erreicht, oder die Batterien waren schon von Anfang an zu schwach. Einfach mal wechseln.

Zitat von: walterschmitz am 28 November 2017, 23:28:42
Für mich ist die Verzögerung nicht nachvollziehbar, da ja nur der Befehl an das WT geht. Warum sendet WT dann nicht direkt weiter.

Kann ich nicht erklären, habe ich bisher nicht bemerkt, weil nicht beobachtet. Ich lade ein Wochenprogramm auf den WT und gut, ich steuere keine Temperaturänderungen über FHEM.

Was bedeutet denn zeitliche Verzögerung für dich? 10 Sekunden, 1 Minute, 10 Minuten, oder evtl. bis zum nächsten Schaltvorgang im Wochenprogramm?

Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

walterschmitz

Hallo,

also wenn ich am WT direkt etwas einstelle, dann ist das HT quasi sofort auch umgestellt (ich würde einen Zeitrahmen von wenigen Sekunden hier als real bei mir abschätzen).
Schalte ich via FHEM, so stellt sich das WT auch nach wenigen Sekunden um, jedoch ist beim HT lange Zeit (ich vermute es ist irgendwann ein (Schalt)Zeitpunkt, wann das umgestellt wird)... aber genau kann ich das nicht messen und / oder abschätzen. Das ist jedes mal unterschiedliche... Teilweise auch mehrere Minuten.

So kann es z.B. auch schon mal sein, dass ich am FHEM -> WT (21 Grad) einstelle... -> HT keine Änderung. In der Zwischenzeit ändert sich am HT die desiredTemp z.B. durch eine Automatik im HT und dann springt das WT nach einiger Zeit wieder auf die alte Einstellung (genau vor meiner Umstellung ohne mein Zutun).

Von daher frag ich mich auch manchmal... geb ich besser das gleiche Programm dem WT UND dem HT? Oder reicht es wirklich, wenn das WT die Automatik programmiert bekommt.

Wenn BEIDE (WT UND HT) eine Automatik haben, die ggf. leicht unterschiedlich ist... wer gewinnt das bzw. hat die "Macht" - wenn ich das mal so sagen kann.

Z.B: WT steht von 00:00 - 09:00 Uhr auf 19 Grad (durch eine programmierte Automatik)
HT als Standardautomatik (also nicht von mir verstellt) stellt um 06:00 Uhr auf 21 Grad.
Sprich um 6 Uhr heizt HT erst einmal hoch, bis irgendwann WT den diseredTemp erneut überträgt und dem HT wieder die 19 Grad vorgibt.

Auf jeden Fall versteh ich nicht... Einstellung an FHEM -> WT brauchen länger zur Übertragung an HT als direkt am WT eingestellt... Wäre das sofort eingestellt, würde vermutlich HT auch nicht im o.a. Beispiel kurz hochheizen, denke ich.

Gruß

walterschmitz

Zitat von: willyk am 29 November 2017, 11:48:33
Was bedeutet denn zeitliche Verzögerung für dich? 10 Sekunden, 1 Minute, 10 Minuten, oder evtl. bis zum nächsten Schaltvorgang im Wochenprogramm?

Halloo zusammen,

also... es hat ein bisschen gedauert, bis ich das ganze mit Fakten belegen konnte.

Heute morgen aber ganz krass:

über FHEM an WT den Befehl gegeben desiredTemp: Boost
direkt nach Einstellungen an FHEM kann ich Display von WT auch den Timer von 300 runterlaufen.
am HT passiert gar nichts und es bleibt "stumm"

Gehe ich im Gegenzug direkt an das WT und drücke die Boost-Taste, dann kommt innerhalb von 1-2 sek. auch der Boost am HT... also quasi Zeitgleich.

Erklären kann ich das nicht, warum es von WT an HT weitergegeben wird und von FHEM an WT und dann nichts mehr.

Selbstverständlich waren das beim Testen die gleichen Geräte.

willyk

Zitat von: walterschmitz am 10 Dezember 2017, 22:08:21
über FHEM an WT den Befehl gegeben desiredTemp: Boost
direkt nach Einstellungen an FHEM kann ich Display von WT auch den Timer von 300 runterlaufen.
am HT passiert gar nichts und es bleibt "stumm"

Ich verstehe das Problem nicht. Es passiert genau das was du per FHEM angeordnet hast: der WT ist im boost Modus. Habe das gerade bei mir versucht, es ist das gleiche Verhalten: WT im boost, HTs machen nichts.

Jetzt im Ernst: ich verstehe was Du erreichen möchtest. Allerdings steht nirgends dass das auch so funktionieren wird. Zitat von früher: "Überleg mal: die Geräte funktionieren eigentlich ohne FHEM."

Wir sind uns vermutlich einig, dass die Max-Geräte (ohne fhem) korrekt funktionieren. Eingaben vom WT werden an HT weitergeleitet, HT Eingaben werden an WT weitergeleitet, jeweils ohne Verzögerung.

Mit fhem ist das dann anders: wenn fhem nun z.B. eine Änderung der Soll-Temperatur an den WT sendet, was passiert dann (sofort) mit den HTs? Nichts. Warum? Weil der WT erst bei der weiteren Kommunikation mit den HTs die neue Soll-Temperatur berücksichtigt. Das Verhalten ist eben ein wenig anders wie wenn du direkt am WT deine Eingaben machst. Nirgends steht dass der WT sofort neue Einstellungen an die HTs weitergibt.

Nur ein Gedanke, nicht verprobt / getestet: Vielleicht nutzt es etwas, wenn du die WTs und HTs in die gleiche Gruppe hängst. Dann fühlen sich alle Geräte der gleichen Gruppe von dem boost angesprochen.

Viel Erfolg
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

walterschmitz

Zitat von: willyk am 11 Dezember 2017, 08:59:20
Ich verstehe das Problem nicht. Es passiert genau das was du per FHEM angeordnet hast: der WT ist im boost Modus. Habe das gerade bei mir versucht, es ist das gleiche Verhalten: WT im boost, HTs machen nichts.
Also ist das normal, das jetzt nur Boost nicht weitergeleitet wird.

Zitat von: willyk am 11 Dezember 2017, 08:59:20
Jetzt im Ernst: ich verstehe was Du erreichen möchtest. Allerdings steht nirgends dass das auch so funktionieren wird. Zitat von früher: "Überleg mal: die Geräte funktionieren eigentlich ohne FHEM."
Wir sind uns vermutlich einig, dass die Max-Geräte (ohne fhem) korrekt funktionieren. Eingaben vom WT werden an HT weitergeleitet, HT Eingaben werden an WT weitergeleitet, jeweils ohne Verzögerung.
Soweit seh ich das gerade genauso wie du / ihr.
Zitat von: willyk am 11 Dezember 2017, 08:59:20
Mit fhem ist das dann anders: wenn fhem nun z.B. eine Änderung der Soll-Temperatur an den WT sendet, was passiert dann (sofort) mit den HTs? Nichts. Warum? Weil der WT erst bei der weiteren Kommunikation mit den HTs die neue Soll-Temperatur berücksichtigt. Das Verhalten ist eben ein wenig anders wie wenn du direkt am WT deine Eingaben machst. Nirgends steht dass der WT sofort neue Einstellungen an die HTs weitergibt.
Mir geht es auch nicht darum, dass es DIREKT am HT weitergeleitet wird!!! Schön wäre das, das geb ich zu, aber ich kann mir herleiten, warum ich manchmal warten muss. Aber... mir geht's darum, dass das WT in meinem Beispiel den Boost-Befehl annimmt und beginnt zu zählen. Aber jetzt wäre es doch so, dass das HT beim nächsten Update durch WT den Boost-Auftrag auch bekommen müsste? Oder funktioniert es bei Boost einfach nicht und nur bei konkreten (desired) Werten? Eigentlich würde ich meinen, dass ich via FHEM einen WunschTemp-Wert übermittele und dieser nach kurzer Wartezeit an HT übertragen wird - soweit spricht da ja auch nichts gegen.
Aber, dass es gar nicht weitergegeben wird? Hm... das fänd ich dann schon komisch.

Wie du schon sagst, MAX funktioniert auch ohne FHEM... aber wenn das WT einen Wert (egal ob von mir oder von FHEM) erhält... dann sollte es beim nächsten Updaten doch HT entsprechend informieren bzw. einstellen.

Zitat von: willyk am 11 Dezember 2017, 08:59:20
Nur ein Gedanke, nicht verprobt / getestet: Vielleicht nutzt es etwas, wenn du die WTs und HTs in die gleiche Gruppe hängst. Dann fühlen sich alle Geräte der gleichen Gruppe von dem boost angesprochen.
Das mit der Gruppe schau ich mir mal an. Hab ich bislang nie genutzt bzw. eingesetzt.
Aber lt. Commandref ist es das hier:
For devices of type HeatingThermostat only. Writes the given group id the device's memory. To sync all devices in one room, set them to the same groupid greater than zero.
Da ich nur EIN WT und EIN HT habe und es nur auf HT wirkt - unterstelle ich, dass es mir keinen Benefit bringen würde.
Das wäre nach meinem Verständnis dann eher in großen Räumen, wenn ich mehrere HT mit einem WT steuern möchte.

Gruß