Also jetzt bin ich verwirrt - rpi, fhem, HMLAN, TC und VD's

[frankygth]

Ich bin verwirrt !!! Schöne Grüße ans Forum und Hilfe.....

Ist Situation:
RPi mit FHEM, 1xHMLAN, 1xHM-CC-TC und 3x HM-CC-VD

Vorgehensweise bisher:
Zuerst hab ich die HM-CC-VD's am TC angelernt. Somit war die Regelung der Temperatur über den TC möglich.

Danach hab ich den TC und die VD's über die Homematic Software und HMLAN angelernt. Alle Geräte sind in der Software ersichtlich!

Danach hab ich den HMLAN im FHEM eingetragen und zuerst TC und dann die VD's in FHEM mittels autocreate angelernt.

Die config wurde geschrieben und von mir wurden die Namen angepasst. Steuerung über FHEM ist auch möglich (set Temperature).

Womit ich Probleme habe bzw. was ich noch nicht so ganz verstehe!

Er will die Temperaturlisten nicht nehmen? Diese wurden so wie im WIKI erstellt und mittels Reload 99_MyUtils.pm bzw. dem Aufruf der Liste direkt eingelesen.
Im Log tauchen die Listen auch auf, allerdings irgendwie kein confirm. Und gestellt wird gar nichts (TC läuft im Auto Modus)

Seit kurzem ist mir aufgefallen, dass ich beim einlesen der Liste (nur 1 TC und nur 1 Woche) HMLAN overload bekomme???

Was ich überhaupt nicht verstehe?

Muss ich die VD's jetzt noch irgendwie mit dem CUL_Climate channel paaren? Oder das TC.
Ist die Config soweit in Ordnung? Mit den Diagrammen hab ich noch so meine Probleme.....

Mein Ziel: Derzeit Heizungssteuerung mit Temperaturlisten, danach Erweiterung mit Fensterkontakten (wobei ich da noch nicht verstanden habe, wass besser ist, Drehgriff oder Kontakt??)
Vielleicht kann mir das auch wer beantworten.)
Danach noch 2-3 "neue" Heizungssteuerungsmodule (die ohne externem Thermostat) - sowie in weiterer Folge - XBMC, Panasonic TV, Dreambox....   Funksteckdosen bzw. vielleicht Licht

###################################################################
Meine Config: (SN bzw. ID's ausgeblendet!)

attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\\\\\\
\\\\\\
WEB,WEBtablet has no basicAuth attribute.\\\\\\
telnetPort has no password/globalpassword attribute.\\\\\\
\\\\\\
Restart fhem for a new check if the problem is fixed,\\\\\\
or set the global attribute motd to none to supress this message.\\\\\\

attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global userattr devStateIcon devStateStyle icon sortby webCmd
attr global verbose 3

define telnetPort telnet 7072 global

define WEB FHEMWEB 8083 global

define WEBphone FHEMWEB 8084 global
attr WEBphone basicAuth
attr WEBphone stylesheetPrefix smallscreen

define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog

define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log

define eventTypes eventTypes ./log/eventTypes.txt

# Disable this to avoid looking for new USB devices on startup
#define initialUsbCheck notify global:INITIALIZED usb create


##################################################################################

#############################
#                 HMLAN
#############################

define HMLAN1 HMLAN 192.168.65.45:1000
attr HMLAN1 hmId
attr HMLAN1 hmLanQlen 1_min
attr HMLAN1 wdTimer 25

##############################
###           THERMOSTAT                ###
##############################

define THERMOSTAT CUL_HM
attr THERMOSTAT .devInfo 00FFFF
attr THERMOSTAT .stc 58
attr THERMOSTAT actCycle 000:10
attr THERMOSTAT actStatus unknown
attr THERMOSTAT expert 2_full
attr THERMOSTAT firmware 2.1
attr THERMOSTAT model HM-CC-TC
attr THERMOSTAT peerIDs
attr THERMOSTAT room WOHNZIMMER
attr THERMOSTAT serialNr
attr THERMOSTAT subType unknown

#LOG
define FileLog_THERMOSTAT FileLog ./log/THERMOSTAT-%Y.log THERMOSTAT:.*
attr FileLog_THERMOSTAT logtype temp4hum6:Temp/Hum,text
attr FileLog_THERMOSTAT room WOHNZIMMER

#DIAGRAMM
define weblink_THERMOSTAT weblink fileplot FileLog_THERMOSTAT:temp4hum6:CURRENT
attr weblink_THERMOSTAT label "THERMOSTAT Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_THERMOSTAT room Plots

#CUL_Weather
define CUL_Weather CUL_HM
attr CUL_Weather expert 1
attr CUL_Weather model HM-CC-TC
attr CUL_Weather peerIDs
attr CUL_Weather room WOHNZIMMER

#LOG
define FileLog_CUL_Weather FileLog ./log/CUL_Weather-%Y.log CUL_Weather
attr FileLog_CUL_Weather logtype text
attr FileLog_CUL_Weather room WOHNZIMMER

#CUL_Climate
define CUL_Climate CUL_HM
attr CUL_Climate expert 1
attr CUL_Climate model HM-CC-TC
attr CUL_Climate peerIDs
attr CUL_Climate room WOHNZIMMER

#LOG
define FileLog_CUL_Climate FileLog ./log/CUL_Climate-%Y.log CUL_Climate
attr FileLog_CUL_Climate logtype text
attr FileLog_CUL_Climate room WOHNZIMMER

#CUL_WindowRec
define CUL_WindowRec CUL_HM
attr CUL_WindowRec expert 1
attr CUL_WindowRec model HM-CC-TC
attr CUL_WindowRec peerIDs
attr CUL_WindowRec room WOHNZIMMER
attr CUL_WindowRec stateFormat last:trigLast

#LOG
define FileLog_CUL_WindowRec FileLog ./log/CUL_WindowRec-%Y.log CUL_WindowRec
attr FileLog_CUL_WindowRec logtype text
attr FileLog_CUL_WindowRec room WOHNZIMMER

#ActionDetector
define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 600
attr ActionDetector event-on-change-reading .*
attr ActionDetector room WOHNZIMMER

#LOG
define FileLog_ActionDetector FileLog ./log/ActionDetector-%Y.log ActionDetector
attr FileLog_ActionDetector logtype text
attr FileLog_ActionDetector room WOHNZIMMER

############################
###          HZ_KUECHE                ###
############################

define HZ_KUECHE CUL_HM
attr HZ_KUECHE .devInfo 010100
attr HZ_KUECHE .stc 58
attr HZ_KUECHE actCycle 028:00
attr HZ_KUECHE actStatus unknown
attr HZ_KUECHE expert 2_full
attr HZ_KUECHE firmware 2.0
attr HZ_KUECHE model HM-CC-VD
attr HZ_KUECHE peerIDs
attr HZ_KUECHE room WOHNZIMMER
attr HZ_KUECHE serialNr
attr HZ_KUECHE subType thermostat

#LOG
define FileLog_HZ_KUECHE FileLog ./log/HZ_KUECHE-%Y.log HZ_KUECHE
attr FileLog_HZ_KUECHE logtype text
attr FileLog_HZ_KUECHE room WOHNZIMMER

########################################
###                 WZ_WOHNZIMMER                      ###
########################################

define HZ_WOHNZIMMER CUL_HM
attr HZ_WOHNZIMMER .devInfo 010100
attr HZ_WOHNZIMMER .stc 58
attr HZ_WOHNZIMMER actCycle 028:00
attr HZ_WOHNZIMMER actStatus unknown
attr HZ_WOHNZIMMER expert 2_full
attr HZ_WOHNZIMMER firmware 2.0
attr HZ_WOHNZIMMER model HM-CC-VD
attr HZ_WOHNZIMMER peerIDs
attr HZ_WOHNZIMMER room WOHNZIMMER
attr HZ_WOHNZIMMER serialNr
attr HZ_WOHNZIMMER subType thermostat

#LOG
define FileLog_HZ_WOHNZIMMER FileLog ./log/HZ_WOHNZIMMER-%Y.log HZ_WOHNZIMMER
attr FileLog_HZ_WOHNZIMMER logtype text
attr FileLog_HZ_WOHNZIMMER room WOHNZIMMER

#########################################
###                  HZ_VORRAUM                              ###
#########################################

define HZ_VORRAUM CUL_HM
attr HZ_VORRAUM .devInfo 010100
attr HZ_VORRAUM .stc 58
attr HZ_VORRAUM actCycle 028:00
attr HZ_VORRAUM actStatus unknown
attr HZ_VORRAUM expert 2_full
attr HZ_VORRAUM firmware 2.0
attr HZ_VORRAUM model HM-CC-VD
attr HZ_VORRAUM peerIDs
attr HZ_VORRAUM room WOHNZIMMER
attr HZ_VORRAUM serialNr
attr HZ_VORRAUM subType thermostat

#LOG
define FileLog_HZ_VORRAUM FileLog ./log/HZ_VORRAUM-%Y.log HZ_VORRAUM
attr FileLog_HZ_VORRAUM logtype text
attr FileLog_HZ_VORRAUM room WOHNZIMMER

###################################################################

[unimatrix]

Hi,

ich habe mir deine Config jetzt nicht genau angesehen, aber ich glaube es ist "nicht gut" die TCs mit den VDs als erstes (ohne angelernte Zentrale/FHEM) zu paaren. Stattdessen sollten die beiden im Werkszustand zuallererst an FHEM angelernrt werden und dann mit dem Kommando peerChan die Peers eingetragen werden (also das "Anlernen zwischen VDs und TC").

Ansonsten mach nach dem Schreiben der temilisten ein getConfig (falls nicht automatisch) und schaue dir an, ob die templisten in den REadings stimmen und auf verified stehen. Wenn nicht, poste doch mal die Readings hier.

VG!

[frankygth]

So, ich hab jetzt den TC und die 3 VD's redetet!

Danach TC mit FHEM gepaired sowie die 3 VD's
Die Config angepasst, bzw. die Devices umbenannt.

Womit ich jetzt nicht klar komme, ist das peering vom TC mit den VD's (Climate Channel).
Hab folgenden Befehl, aus anderem Thread probiert: set CUL_HM_HM_CC_TC_XXXXXX_Climate peerChan 0 CUL_HM_HM_CC_VD_XXXVD1 single

Im Logfile sieht das dann so aus:
2013.10.21 04:58:32 2: CUL_HM set CUL_Climate peerChan 0 HZ_VORRAUM single
2013.10.21 04:58:34 2: HMLAN_Parse: HMLAN1 new condition ok
2013.10.21 05:00:35 2: CUL_HM set CUL_Climate peerChan 0 HZ_WOHNZIMMER single
2013.10.21 05:00:47 2: HMLAN_Parse: HMLAN1 new condition Warning-HighLoad
2013.10.21 05:00:52 2: CUL_HM set CUL_Climate peerChan 0 HZ_KUECHE single
2013.10.21 05:00:54 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload

Eigenartigerweise bekomme ich immer Overload.....

Was mache ich falsch?

[unimatrix]

Hast du möglicherweise vorher FHEM mehrmals neu gestartet? Dann "vergisst" FHEM die Load des HMLAN und überläd ihn. Nach einer Stunde spätestens müsste der Spuk vorbei sein und dann solltest du es nochmal testen. Ist im Moment leider so. Andere Möglichkeit ist es, den HMLAN kurz stromlos zu machen. Dann vergisst er seinerseits dass er vorher schon so viel geackert hatte...

VG

[frankygth]

So, jetzt hab ich nochmal angefangen ...

Status: TC und 1x VD konnte ich erfolgreich pairen und auch das peering hat funktioniert.
Die ID sehe ich, allerdings wollen die anderen nicht so wirklich.
Obwohl, jetzt scheint da was eingetragen worden sein....

Wieviel ID Einträge müssen da denn sein, pro VD? Vermutlich 2, oder - Dann scheint es jetzt OK zu sein....

Vielen Dank!

[martinp876]

ein VD kann nur einen peer. Macht auch sonst keinen sinn - es kann einfach nicht sein, dass 2 TCs ventilwerte vorgeben - was sollte der VD damit machen?

ein TC kann - glauben ich - 4 VDs. Das macht schon sinn, da der TC einfach die gleichen Regelwerte an die VDs sendet. Unterschiede werden durch die programmierbaren offsets eingestellt.

[frankygth]

So, irgendwie haut das immer noch nicht so richtig hin.... Die Templisten werden nicht abgearbeitet (im Auto Modus)

Grundsatzfrage:

Wenn ich den TC mit den 3 VD's paaren, habe ich ja ein eigenständiges System. Der TC sendet ja die Werte and die VD's.

Wenn ich dann den TC in FHEM anlerne und danach die VD's habe ich doch den Vorteil, dass die Steuerung über fhem vorgenommen werden kann, Log, Diagramme, etc.
Und die Werte der VD's werden ebenfalls angezeigt, sozusagen sehe ich wieviel % notwendig sind, um die Temperaturen zu erreichen.

Wenn ich das richtig verstanden habe, kann fhem ja nicht direkt mit den VD's kommunizieren, sozusagen funktioniert die Steuerung ja imm über den TC, welcher eben

a) durch die Betätigung des Rades die Temperatur verändert werden kann, oder

b) über fhem Web bzw. IOS die Werte an das TC übergeben werden.

Das TC läuft im Auto Modus und kann so eben mittels a) oder b) Veränderungen vornehmen.

Mir ist nicht genz klar, wie ich die internen Termperaturlisten vom TC überschreiben kann (durch fhem)? Die 99_MyUtils.pm hab ich laut WIKI angelegt und mit den Werten befüllt.
Danach ein Reload 99_MyUtils.pm aufgerufen und die SUB aufgerufen mittels - {SetTempList_THERMOSTAT} aufgerufen. Man spricht ja direkt den Climate Channel an, oder etwa nicht?

Mir ist nicht ganz klar, worin der Vorteil liegt, wenn ich TC und danach VD direkt in fhem anlerne, bzw. dann das peering mache? Was ist der Vorteil gegenüber der vorzeitigen Verbindung von TC und VD's and anschließend fhem. Ich steh da wohl ein bisschen auf der Leitung.
Eigenartigerweise findet sich da auch kein vernünftiges HowTo, ich denke schon, dass die Problematik einige betrifft.

So sieht die 99_MyUtils.pm bei mir aus...


package main;
use strict;
use warnings;
use POSIX;
sub
myUtils_Initialize($$)
{
my ($hash) = @_;
}
1;

######################################################
# Temperatur-Liste für das Wohnzimmer
# setzen per Aufruf von "{SetTempList_THERMOSTAT}"
######################################################
sub
SetTempList_THERMOSTAT()
{
  { fhem ("set CUL_Climate tempListMon 05:30 17.0 09:15 23.0 16:00 19.0 20:30 20.5 24:00 17.0")};
  { fhem ("set CUL_Climate tempListTue 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0")};
  { fhem ("set CUL_Climate tempListWed 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0")};
  { fhem ("set CUL_Climate tempListThu 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0")};
  { fhem ("set CUL_Climate tempListFri 05:30 17.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.0")};
  { fhem ("set CUL_Climate tempListSat 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
  { fhem ("set CUL_Climate tempListSun 07:00 17.0 09:00 21.0 18:00 22.0 21:00 21.0 24:00 17.0")};
}
# End SetTempList_THERMOSTAT

[martinp876]

Generall akzeptieren nur gepairte devices kommandos und einstellungen von der Zentrale
das der TC an FHEM gepairt werden sollten ist - denke ich - klar- jedenfalls wenn du von der Zentrale regelwerte oder modi setzen willst, peeren willst oder templisten programmieren willst.
Das pairen eines VD bringt nicht so viele Vorteile. Immerhin kann man peers setzen und löschen, error-werte sowie ventil-offsets in die register schreiben (siehe register-liste).
FHEM kann in den VD schreiben oder lesen - alle ~3min - aber nur (und genau dann), wenn der TC ihn aufweckt.

der TC sendet temperatur-readings an die Zentrale, wenn er eine Zentrale kennt.

Grundsätzlch hat HM die Devices ausgelegt um sie auch ohne Zentrale nutzen zu können - alles kann man aber nicht machen.

natürlich kannst du die templisten von FHEN aus schreiben und lesen. hast du schon einmal die Kommandolisten angesehen? ist dir tempListSat... aufgefallen?

Man kann immer erst peeren ind dann pairen - macht keinen Unterschied. Da ich aber nur eine Variante beschreibe (ist schon aufwand genug) und nach dem pairen das direkte peeren nicht mehr geht ist das direkte peeren nicht der von mir beschriebene weg.
Merke: wenn ein device gepairt ist verliert es seine Selbstständigkeit - es kann dann z.B. nicht mehr direkt peeren. HM hat das direkte peeren sicher nur als Notlösung eingebaut um Usern ohne Zentrale auch leben zu lassen - eigentlich wollen auch sie alles über die Zentrale lösen.

Gruss Martin

[frankygth]

Danke Martin

Also ist meine grundsätzliche Vorgehensweise richtig?

Reset, fhem leer nur mit Hmlan Einträgen!

Danach das pairing vom TC, anschließend VD

Danach peering, also Zuordnung VD zu TC, wenn das erfolgreich ist, tauchen ja die perrIDs in der config auf.
Ich hab den Befehl in die fhem.cfg eingetragen, also den climate Channel mit meinen 3 vds gepeert.
Nach einem getConfi über die Weboberfläche waren die Befehle scheinbar angewendet und aus der cfg verschwunden.

Ich kann somit per TC steuern, bzw. auch per Web oder Tablet. Ist doch richtig so, bis jetzt, oder ?

Was ist denn an der Sat Temp Liste falsch?

Bzw. Muss ich den Aufruf der Liste Fix in die cfg schreiben, oder reicht es, wenn das über die Zeile im Web einmalig aufgerufen wird....

Vielen Dank für die Hilfestellung, schon faszinierend, was da alles so geht...

[martinp876]

Hallo,

pairen ist korrekt, reihenfolge egal

peeren und temp-liste setzen macht man nicht im fhem.cfg. das führst du nur einmal aus.

Mir ist nicht klar, wie du dir das System vorstellst - also einmal ein paar Fakten:
- alles was du in fhem.cfg einträgst wird bei jedem restart/reread ausgeführt
- peeren und register werden nicht in FHEM sondern IM hm-device gespeichert- und zwar permanent
- das gilt auch für temp-listen
- wenn man wissen will, was im device steht (peers/templisten/register) muss man ein getConfig machen, es lesen gehen
- wenn du die Register (auch temp-list ) bei jeden neustart schreiben willst belastet das die HMLAN performance und sicher auch das flash den RT. Und es ist schlichtweg sinnlos.

Also: templisten schreibt man nur einmal - und dann nur noch, wenn man sie ändern will

ferner solltest du, wenn du mehr  listen auf einmal schreiben willst mit "prep/exec" arbeiten. Der RT macht nach jeden schreiben ein päuschen - da hat der nächste Schreibbefehl dann ein Problem. Daher gibt es prep-exec

set CUL_Climate tempListMon prep 05:30 17.0 09:15 23.0 16:00 19.0 20:30 20.5 24:00 17.0
set CUL_Climate tempListTue prep 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
set CUL_Climate tempListWed prep 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
set CUL_Climate tempListThu prep 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
set CUL_Climate tempListFri prep 05:30 17.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.0
set CUL_Climate tempListSat prep 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
set CUL_Climate tempListSun exec 07:00 17.0 09:00 21.0 18:00 22.0 21:00 21.0 24:00 17.0


Gruss Martin

[frankygth]

Danke Martin für die Ausführung...

Jetzt verstehe ich einige Dinge besser, man findet halt wenn man liest die verschiedensten Ansätze...
Und probiert sich so durch.....

Ich werde das mit den TempListen mal testen.... Danke