Peering von mehreren Heizkörperregler und Temperaturfühler/Fensterkontakt

Begonnen von Superposchi, 09 Januar 2024, 22:57:29

Vorheriges Thema - Nächstes Thema

rabehd

Dann mach mal ein Fenster auf und schau auf den gepeerten Thermostat.
Dann das gleiche ohne Peer.
Auch funktionierende Lösungen kann man hinterfragen.

Superposchi

Der Regler reagiert natürlich und senkt/erhöht die Temperatur. Aber das kann ich doch auch per Fhem-Befehl umsetzen indem ich den Fensterkontakt triggere und entsprechend per DOIF den Regler öffne/schließe.

Außer dass es automatisch passiert, wo ist der Vorteil?

MadMax-FHEM

Zitat von: Superposchi am 11 Januar 2024, 10:05:31Der Regler reagiert natürlich und senkt/erhöht die Temperatur. Aber das kann ich doch auch per Fhem-Befehl umsetzen indem ich den Fensterkontakt triggere und entsprechend per DOIF den Regler öffne/schließe.

Außer dass es automatisch passiert, wo ist der Vorteil?

Direkt, also mit Peerring geht halt sofern keine Funkstörung da ist, also auch OHNE fhem.

Gleiches bei Taster/Schalter und Aktor: du drückst und der Taster/Schalter schickt direkt ein Telegramm zum Aktor und der schaltet auch ohne fhem.

Ich habe gerne, dass es auch ohne fhem geht (nicht, dass fhem schlecht läuft aber...).

Kann ja jeder selber umsetzen wie er will... 8)

Dass die Devices unterschiedlich ausshen, hmmm.

Der einzige große Unterschied ist: es gibt Devices OHNE Kanal (Fensterkontakt) und welche mit Kanälen (eigentlich alle anderen).

Ich denke, dass das schon seitens Homematic/eq3 so "gedacht" ist, müsste man mal schauen, wie es in einer CCUx aussieht...
So hat jeder Kanal eben seine "Aufgabe" (hatte ich ja schon geschrieben).

Auch bzgl. lists ja "korrigiert": die Infos die "wir" brauchen bei deinen aktuellen Fragen ("Homematic generell und ein paar Spezialitäten") habe ich mir inzwischen zusammengesammelt...

Bzgl. Verständnis wie CUL_HM/Homematic funktioniert wirst du dich halt mal einlesen und ausprobieren "müssen"...
...und bei speziellen Fragen wieder hier aufschlagen.
Und halt ebenso auch die BD zu den Geräten lesen und einfach Zentrale durch fhem "ersetzen" ;)

Bzgl. Pairing: im Forum stehen 10000 von Pairing geht nicht, cmds_pending geht nicht weg usw.
Meist ist es zu wenig Geduld und gerade bei Batterie-Geräten, die müssen ja immer mal wach werden bevor sie wieder senden (manchmal hilft auch "zwangsaufwecken" durch "Knöpfchendrücken" ;)  ) und gerade beim Pairing mit (vielen) Kanälen ist halt einiges zu übertragen...

Wichtig ist halt, dass korrekt und komplett (zu ende) gepaired ist, ansonsten bekommt man zwar von "Sensoren" (z.B. Fensterkontakt) die Werte in fhem (es ist Funk, fhem empfängt und trägt die Werte bei einem "passenden" Device ein) aber man kann keine Register setzen (-> auch nicht peeren, ist ja auch setzen eines Registers) und Aktoren nicht steuern (nimmt nur Befehle von Peers bzw. Zentrale an).
https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen
https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen#Pairing_verifizieren

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Superposchi

Das war ja eins der Hauptprobleme.
Nachdem die Devices angelegt waren bin ich erstmal davon ausgegangen, dass das pairing funktioniert hat.
Erst nachdem nach zwei Tagen immer noch nichts lief habe ich angefangen zu recherchieren und bin dann eben über das cmd_pending auf den Hinweis mit dem Pairing per Seriennummer gestoßen was dann auf Anhieb geklappt hat.

Was die Funktionalität des peerens angeht, ist es also lediglich der Vorteil, beim Ausfall von Fhem. Was ja auch ein Argument ist.
Aber schnellere Befehlsbearbeitung oder sowas liegt nicht dadurch vor?

Ich wollte den Regler nämlich im manuellen Modus per Fhem steuern und auf Ereignisse wie Anwesenheit oder Schlafengehen/Aufstehen mit Zusenden fester Temperaturwerte reagieren. Der Automatikbetrieb ist zwar mit dem Weekprofile gut steuerbar aber für meine Verhältnisse mit Wechselschicht etc. noch zu starr im Ablauf.

MadMax-FHEM

Zitat von: Superposchi am 11 Januar 2024, 10:59:00Was die Funktionalität des peerens angeht, ist es also lediglich der Vorteil, beim Ausfall von Fhem. Was ja auch ein Argument ist.
Aber schnellere Befehlsbearbeitung oder sowas liegt nicht dadurch vor?
Kommt drauf an wie lange fhem braucht ;)

Bei gepeerten Geräten geht das Funktelegramm halt direkt/sofort zum "Partnergerät"...
...bei fhem ist halt fhem dazwischen: fhem empfängt, macht was und sendet...

Zitat von: Superposchi am 11 Januar 2024, 10:59:00Ich wollte den Regler nämlich im manuellen Modus per Fhem steuern und auf Ereignisse wie Anwesenheit oder Schlafengehen/Aufstehen mit Zusenden fester Temperaturwerte reagieren. Der Automatikbetrieb ist zwar mit dem Weekprofile gut steuerbar aber für meine Verhältnisse mit Wechselschicht etc. noch zu starr im Ablauf.
Wie geschrieben: muss/darf/kann jeder nach seinen Bedürfnissen machen...

Starr, ja. Kommt drauf an wie oft sich das ändert. Ich habe verschiedene Profile hinterlegt (3-4) und wechsle nach Bedarf aber meist bleibt es dann einige Tage...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Superposchi

Bei mir wechselt es oft Tageweise um 1-2 Stunden und dazu kommt meine Freundin noch mit Wechselschicht, was quasie alles noch mal verdoppeln würde.
Spontan glaube ich nicht das das Wochenprofil funktionieren würde, ich müsste quasie jeden Tag das Profil wechseln und das per Fernzugriff, da ich oft morgens nicht weiß wann ich Abends die Arbeit beende. Oder ich müsste so ein großes Zeitfenster einplanen, dass alles abgedeckt wäre, dann wäre aber die Ersparnis durch reduzierte Temperaturen eher gering befürchte ich. Früher war mit festen Bürozeiten alles etwas besser planbar finde ich.

Werde jedenfalls die Geräte untereinander noch peeren, Der Ausfall von Fhem ist ein gutes Argument.
Worauf setzt der Regler denn beim Schalten die Werte? Zum Beispiel beim Fensterkontakt kann man ja aine Temperatur für offen angeben, aber wie ist das beim Schließen? Geht er dann auf die vorher eingestellte Temperatur oder auch eine fest eingestellte? Dazu habe ich nichts gefunden bisher.

rabehd

Zitat von: Superposchi am 11 Januar 2024, 10:59:00Ich wollte den Regler nämlich im manuellen Modus per Fhem steuern und auf Ereignisse wie Anwesenheit oder Schlafengehen/Aufstehen mit Zusenden fester Temperaturwerte reagieren. Der Automatikbetrieb ist zwar mit dem Weekprofile gut steuerbar aber für meine Verhältnisse mit Wechselschicht etc. noch zu starr im Ablauf.
Das ist kerin Hindernis fürs Peeren.
Einen Automatikbetrieb gibt es nicht, denn das ist das was du definierst. Also alles was Du selbst nicht direkt am Thermostat tust.
Automatikbetrieb kann sein, die interne Zeitschaltuhr des Thermostats, die Reaktion auf einen Peer, die steuerung per fhem...
Du musst dafür den Begriff definieren.

Ich hatte das früher ohne Weekprofile, mit Wechselschichten über Kalender und Wecker. Hat wunderbar funktioniert. (Heute wohne ich ohne solche Heizkörper)
Die Lösung ist immer folgende: Die Technik verstehen, seine Wünsche formulieren, Stück für Stück umsetzen.
Auch funktionierende Lösungen kann man hinterfragen.

Superposchi

ZitatAutomatikbetrieb kann sein, die interne Zeitschaltuhr des Thermostats, die Reaktion auf einen Peer, die steuerung per fhem...
Da hast du Recht, ich meinte die interne Zeitschaltuhr die man mit den Weekprofile -Modul programmieren kann.

Habe jetzt meine eiden Fensterkontakte sowie die beiden Fensterdrehgriffe mit dem Regler gepeert. Zumindest habe ich die dafür vorgesehenen Befehle ausgeführt.
Gibt es in Fhem auch eine Möglichkeit nachzuschauen ob der Peer funktioniert hat oder kann man es nur durch praktisches Ausprobieren testen?

rabehd

Zitat von: Superposchi am 11 Januar 2024, 11:34:35Gibt es in Fhem auch eine Möglichkeit nachzuschauen ob der Peer funktioniert hat oder kann man es nur durch praktisches Ausprobieren testen?
Ich würde da einfach ma lin das Device schauen. Überraschenderweise gibt es ein Internal peerList, ein Reading peerList und ein Attribut peerIDs.
Auch funktionierende Lösungen kann man hinterfragen.

Superposchi

Nein, gibt es bei mir eben nicht.
Es hat sich nichts verändert nach dem Befehl.

Ich habe lediglich das Attribut peerIDs, dort stehen aber nur 8 Nullen drin. Wenn man was sehen könnte hätte ich nicht gefragt.

frank

poste doch mal die ausgabe von "get hminfo configCheck".
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

MadMax-FHEM

Zitat von: Superposchi am 11 Januar 2024, 13:07:50Ich habe lediglich das Attribut peerIDs, dort stehen aber nur 8 Nullen drin. Wenn man was sehen könnte hätte ich nicht gefragt.
Du solltest dir eine vccu einrichten und v.a. hminfo.

Bzw. (wie schon angemerkt) aus der Signatur von Frank hminfotools HMdeviceTools...

Damit kannst du dein System bzgl. CUL_HM prüfen und auch weitere Dinge tun...

https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
https://wiki.fhem.de/wiki/HMinfo

Arbeite erst mal ein wenig mit deinen Homematic Komponenten, dann lernst du schon wie sie ticken usw.
Dauert halt etwas...

ABER: immer Geduld, gerade, wenn Batterie-Geräte dabei sind! Befehle müssen "abgearbeitet" werden und das geht nur, wenn die Dinger wach (und dafür bereit) sind. Bei den Fenstersensoren hilft auch "Config-Knöpfchen" drücken (aber "Achtung" zumindest bei den optischen ein Auslösen während dem Config-Drücken vermeiden)...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Superposchi

Werde ich mal durchlsen und mich mit auseinandersetzen.

Denke das Problem liegt wieder darin, dass die Fensterkontakte nicht richtig gepairt sind.
Die sind in Fhem angelegt aber es steht bei der Mehrzahl ein CMD_pendingobwohl die Devices seit mehr als 3 Jahren nicht angepackt worden sind.
Da Daten zu auf/Zu geliefert wurden ist mir das nie groß aufgefallen.

Werde heute Abend mal alle Geräte neu pairen und kontrollieren.

frank

Zitat von: MadMax-FHEM am 11 Januar 2024, 13:51:54Du solltest dir eine vccu einrichten und v.a. hminfo.
da das reading cfgState existiert, ist hminfo bereits definiert.  ;)


Zitat von: Superposchi am 11 Januar 2024, 13:58:38Werde heute Abend mal alle Geräte neu pairen und kontrollieren.
arbeite lieber die configcheck liste ab.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

MadMax-FHEM

Zitat von: Superposchi am 11 Januar 2024, 13:58:38Denke das Problem liegt wieder darin, dass die Fensterkontakte nicht richtig gepairt sind.
Wie man das prüfen kann hatte ich ja bereits verlinkt

Zitat von: Superposchi am 11 Januar 2024, 13:58:38Die sind in Fhem angelegt aber es steht bei der Mehrzahl ein CMD_pendingobwohl die Devices seit mehr als 3 Jahren nicht angepackt worden sind.
Da Daten zu auf/Zu geliefert wurden ist mir das nie groß aufgefallen.
Wie auch schon erwähnt: es ist Funk. Fhem empfängt (legt ein Device an) und ordnet die Daten einem passenden Device zu. Solange es nur um den Empfang/Sensoren geht -> merkt man es (oft) nicht ;)

Bis man: Register ändern will (z.B. Peeren)

Bei Aktoren merkt man das meist sofort: sie lassen sich nicht steuern. Und: hängen meist "am Netz" und sind "immer wach"...

Zitat von: Superposchi am 11 Januar 2024, 13:58:38Werde heute Abend mal alle Geräte neu pairen und kontrollieren.
Auch hier: GEDULD! NICHTS LÖSCHEN! NICHTS ZURÜCKSETZEN! Einfach erneut das Pairing auf beiden Seiten anstossen (fhem set ... pairForSec X  und dann beim Gerät nach BDA). Bei Batterie-Geräten ab und an mal das "Config-Knöpfchen" drücken (so als würdest du Pairen wollen / "Achtung" manchmal liegen Pairing und Reset eng beeinander, also vom Ablauf her -> BDA lesen).
Solange immer wieder mit RUHE "Knöpfchen drücken" bis keine cmds_pending sind (ab und an Refresh der Webseite, das aktualisiert sich auch mal nicht zuverlässig) bzw. sieht man das auch am Blinken beim Gerät (wenn man das mal öfter gemacht hat ;)  )...

Wie du Pairung prüfen kannst, siehe Link weiter oben...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)