Zweiter Schritt: Homematic Einstieg

[claudio-fhem]

OK, getConfig und kurz auf den Knopf am Sensor gedrückt:

Code Auswählen Erweitern

R-pairCentral 0xZZZZZZ  2019-09-23 11:40:44

sowie in hminfo:

Code Auswählen Erweitern

configCheck done:

templist mismatch
    HM_64AA00_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory

STRIKE! Das hat diesmal geklappt, oder? :-D

Dann könnte ich als nächstes den Temp/Hum-Sensor mit dem Heizkörperventil peeren... Oder spricht da etwas dagegen?

[Otto123]

Ja. Du musst bei dem Sensor immer den Configtaster kurz drücken, der überträgt nicht von selbst.

[Otto123]

Dann könnte ich als nächstes den Temp/Hum-Sensor mit dem Heizkörperventil peeren... Oder spricht da etwas dagegen?

Könntest Du. Ich würde an Deiner Stelle erstmal das Thema mit den tempList.cfg abarbeiten, d.h. Deine Liste vollständig eintragen und sichern oder eine Liste erstellen und importieren. Du weißt ja jetzt wo sie liegt und wie es geht. 

Was ich schon lange fragen wollte: Warum hast Du eigentlich (ich find den nicht hübsch) Sensor genommen und nicht den Wandthermostaten? Die Kosten sind gleich und der Wandthermostat hat vor allem für Dich doch viel mehr Funktionen?

[claudio-fhem]

Hmmm, die INFO

Ja. Du musst bei dem Sensor immer den Configtaster kurz drücken, der überträgt nicht von selbst.

...hätte mir ja auch gestern abend schon weitergeholfen :-D


Zum Sensor: Ich wollte erstmal flexibel bleiben (ob der Sensor beim Heizkörperventil notwendig und gut ist wollte ich auf jeden Fall zuerst probieren), wenn ich ihn nicht für das Heizkörperventil brauche, kann ich ihn an unterschiedlichsten Stellen im Raum/Haus aufstellen. Ich missbrauche solche Geräte (433 MHz) auch schon seit Jahren im Outdoor-Einsatz (Regengeschützt, unter einem großzügigen Dachüberstand von mehr als 1 m...) ohne Verschleiss...

[Otto123]

Hmmm, die INFO


...hätte mir ja auch gestern abend schon weitergeholfen :-D

Ja sorry. Es ist generell so, dass man die Datenübertragung bei allen "nicht Aktoren" / Sensoren anstossen muss. Leider ist die Art und Weise WIE praktisch bei jedem anders. Configtaster geht immer (aber immer "anders"), manche machen lazy config (verzögert von selbst) machen kann man auslösen (Bewegungsmelder) manche darf man nicht auslösen (Fenstersensoren)

Der Wandthermo hat nur einen "Nachteil" er verbraucht mehr Batterie (Wechsel weniger als einmal im Jahr). Dafür zeigt er die Temperatur auch direkt an. Deshalb nehme ich im Zimmer immer den.
Der andere Sensor funktioniert Jahrelang ohne Batteriewechsel.

[claudio-fhem]

Die 433 MHz Funkthermometer/Hum. Einheiten haben auch nur 2x AAA und da ist man auch jährlich beim Batteriewechsel dabei. Daher bin ich froh, dass das HM-Dings 2x AA hat und (wenn auch hübsch hässlich) doch hoffentlich 2 Jahre schafft (wie auch der Heizkörperthermostat? Oder sollte man den vor jeder Heizsaison neu bestücken?).

Wenn sich das externe Thermometer für den Heizkörper bewährt, kann ich immer noch so ein Wandgehänge schiessen...

Was ist lazy config?

PS: Ich hatte überlegt, dem fhem Raspi noch einen USB-stick zu verpassen, um die SD-Karte zu schonen. Ist das Auslagern der Log-Dateien viel Aufwand? Rentiert das? Ich habe Sandisk Karten, davon habe ich bisher auch über längere Zeiträume noch keine kaputt bekommen, aber halt auch noch keine Erfahrung mit fhem und seinen Schreibzugriffen...

[Otto123]

https://www.google.de/search?q=site:forum.fhem.de+lazy+config

USB Stick ist witzlos, das ist die gleiche Technik, also nicht besser als SD Karten.
Ich betreibe FHEM auf mehreren Raspis, bei mir ist noch keine SD Card gestorben.

Mein HM-WDS40-TH-I läuft seit Januar 2016 mit dem ersten Satz. Aber nur als Messer nicht als Peer

[claudio-fhem]

Witzlos nicht ganz, wenn die Karte read-only geht kann sich der Raspi verabschieden, wenn der USB-stick read-only geht nur fhem (oder nur das logging?)...

Ja, die AA sind schon wesentlich ergiebiger, als die AAA Batterien... Bei peering mit dem Funkthermostat verbraucht der Sensor mehr? Ich dachte, der Heizkörperthermostat "liesst dann einfach mit" und betrachtet die Temperatur als für sich relevant?

[Otto123]

Wer weiß schon durch welchen Prozess auf dem Raspi welches Speichermedium so belastet wird, dass es kaputt geht. 
Deshalb: Datensicherung und fertig Wenn das System "Lebenskritisch" ist, muss andere Hardware verwendet werden.

Ich habe nicht gesagt, das er als Peer mehr verbraucht. Ich habe es nur nicht so in Betrieb.
Und ich weiß auch nicht, wie aufwendig die Temperatur vom Sensor wirklich übermittelt wird. Normalerweise wird die Meldung des Sensors von der Zentrale und vom Peer quittiert.
Ob das zu mehr Funkverkehr beim Sensor führt? Ob das Batterie relevant ist? 
Keine Ahnung. 

[claudio-fhem]

Leicht OT: Was machst du mit dem Zero W bei fhem? Ich habe noch einen zero übrig, den ich gerne auf mein mini-fhem mit den paar HM-Geräten ansetzen würde (dümpelt in htop ja immer nur bei ein paar Prozent CPU-Last). Spricht da was dagegen?

[Otto123]

Nö, was sollte dagegen sprechen?
Mein ZeroW hat ne Kamera an Board und soll auf Kommando Bilder schießen und BT Anwesenheit machen. Auch FHEM läuft darauf prima. Ist bei mir aber immer noch in der Bastelphase

[claudio-fhem]

Hmm. Dann wäre aber ein HM-Hütchen doch ganz sinnvoll. Dann braucht's keinen USB-Hub (powered?). Einfach USB-RJ45 mit OTG-Kabel an den Zero...

Aber vielleicht sollte ich erstmal ein paar Wochen mit dem 2er fahre und konfigurieren und meine erst Grafik erstellen. Und ein Zeitprogramm für die eine Schaltsteckdose erstellen.

Und ein zweites Programm in das Heizkörperventil reindrücken (für Abwesenheit...). Tausend Sachen zu machen....

[Otto123]

Keep ist simpel
Wenn LAN und HM-MOD-RPI-PCB dann eher direkt so https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Betrieb_mit_einem_LAN-TTL-Wandler

Aber mach doch erstmal mit dem was Du hast. Der CUL schafft es ja offenbar

[claudio-fhem]

Eine Frage noch zum Heizkörperventil. Da sehe ich unter _Clima:

Code Auswählen Erweitern

state T: 21.7 desired: 21.0 valve: 23

1. ist "23" für valve irgend eine arbiträre Einheit oder heisst das "23% offen"?

2. Wenn die Temp über der Solltemp ist, warum ist das Ventil überhaupt (schon) offen?

[claudio-fhem]

Irgendwie läuft das Heizkörperthermostat nicht wie gedacht.

Ich habe in device info long einen Sollwert von 20.0°C und in Clima Readings "control mode manual", aber eigentlich sollte das doch dem eingegeben Programm folgen und dort ist der Sollwert niemals 20.0, sondern 18 oder 21°C. Bis gestern stand das da auch immer über Tag so (Sollwert 21°C).

Code Auswählen Erweitern

Device name:HM_64AA00
   org ID    :0095  Model=HM-CC-RT-DN
   alias ID :0095  Model=HM-CC-RT-DN
   mode    :config,wakeup,burstCond - activity:alive
   protState : CMDs_done pending: none

   HM_64AA00_Weather state:22.4
   HM_64AA00_Climate state:unpeered
   HM_64AA00_WindowRec state:last:trigLast
   HM_64AA00_Clima state:T: 22.4 desired: 20.0 valve: 0
   HM_64AA00_ClimaTeam state:unpeered
   HM_64AA00_remote state:unpeered

"Desired 20.0" passt aber nicht zum Programm, das ich eingestellt habe.

Und unter Clima als Readings habe ich als Programm:

Code Auswählen Erweitern

R-boostPos

80 %

2019-09-22 19:20:10
R-btnNoBckLight

off

2019-09-22 19:20:10
R-dayTemp

21 C

2019-09-22 19:20:10
R-daylightSaveTime

on

2019-09-22 19:20:10
R-modePrioManu

all

2019-09-22 19:20:10
R-modePrioParty

all

2019-09-22 19:20:10
R-nightTemp

17 C

2019-09-22 19:20:10
R-noMinMax4Manu

off

2019-09-22 19:20:10
R-regAdaptive

on

2019-09-22 19:20:10
R-showInfo

time

2019-09-22 19:20:10
R-sign

off

2019-09-22 19:20:06
R-tempOffset

0.0K

2019-09-22 19:20:10
R-valveOffsetRt

0 %

2019-09-22 19:20:10
R-winOpnBoost

off

2019-09-22 19:20:10
R_0_tempListSat

07:00 18.0 22:00 21.0 24:00 18.0

2019-09-22 23:20:25
R_1_tempListSun

07:30 18.0 22:00 21.0 24:00 18.0

2019-09-22 23:20:25
R_2_tempListMon

06:30 18.0 22:00 21.0 24:00 18.0

2019-09-22 23:20:25
R_3_tempListTue

06:30 18.0 22:00 21.0 24:00 18.0

2019-09-22 23:20:25
R_4_tempListWed

06:30 18.0 22:00 21.0 24:00 18.0

2019-09-22 23:20:25
R_5_tempListThu

06:30 18.0 22:00 21.0 24:00 18.0

2019-09-22 23:20:25
R_6_tempListFri

06:30 18.0 22:00 21.0 24:00 18.0

2019-09-22 23:20:25
R_tempList_State

verified

2019-09-22 23:20:25
ValvePosition

0

2019-10-03 08:07:34
boostTime

-

2019-10-03 08:07:34
controlMode

manual

2019-10-03 08:07:34
desired-temp

20.0

2019-10-03 08:07:34
measured-temp

22.4

2019-10-03 08:07:34
partyEnd

-

2019-10-03 08:07:34
partyStart

-

2019-10-03 08:07:34
partyTemp

-

2019-10-03 08:07:34
state

T: 22.4 desired: 20.0 valve: 0

2019-10-03 08:07:34


Hat da ein Benutzer am Ventil rumgedrückt? Kann ich das Ventil wieder auf "Programm" setzen via FHEM?