Homematic mit Nicht Homematic verbinden.

[disaster123]

Konnte jemand die spontanen Schwankungen beheben?

[der2of6]

Abend,

ja das funktioniert. Ist aktuell noch ein recht neues Feature und kann noch Bugs enthalten. Geht aber bereits. Grob geht es so:

Code Auswählen Erweitern


define virtual_temp CUL_HM 123456 (die hm id muss eindeutig sein)
set virtual_temp virtual 1
rename virtual_temp_Btn1 virtual_temp_Sensor1 (damits sinniger klingt)
set virtual_temp_Sensor1 peerChan 0 dein_rt single

Nun hast du einen virtuellen Temperatursensor. Den musst du jetzt nur noch mit der aktuellen Temperatur deines echten Sensors füttern:

Code Auswählen Erweitern


set virtual_temp_Sensor1 virtTemp 22

Das kannst du dann z.B. mit einem notify machen.


Gruß,
Jan

Hallo,

Ich habe mir auch ein paar HM-CC-RT-DN zum Spielen zugelegt.

Die Ist Temperatur soll dabei von 1-Wire DS18B20 Sensoren kommen.

Die Home Matic Thermostate habe ich in FHEM eingebunden, die 1-Wire Sensoren sind eingebunden und liefern auch brav ihre Werte. Jetzt habe ich mit o.g. Befehlen versucht den 1-Wire Sensor mit dem Thermostat zu verbinden, bin aber kläglich gescheitert.
Wahrscheinlich habe ich vor lauter basteln am Wochenende einen Knoten im Hirn. Kann mich jemand wieder in die richtige Richtung lenken?

[tpm88]

das funktioniert bei mir einwandfrei. Hier nochmal Schritt für Schritt:

1. Virtuelles HomeMatic Device mit _deiner_ HM Id definieren:

Code Auswählen Erweitern

define wz_vT CUL_HM <hmId>

2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen:

Code Auswählen Erweitern

set wz_vT virtual 1

3. Bei uns ist es kein virtueller Button sondern ein virtueller Temperatursensor - darum rename:

Code Auswählen Erweitern

rename wz_vT_Btn1 wz_vT_Sensor1

4. Virtuellen Peer Sensor mit dem Weather Channel deines RT-DN peeren:

Code Auswählen Erweitern

set wz_vT_Sensor1 peerChan 0 <RT_DN>_Weather single

5. Peering kontrollieren (Voraussetzung: Device hm vom Type hmInfo existiert):

Code Auswählen Erweitern

set hm peerXref
Beispiel-Ausgabe bei mir:

Code Auswählen Erweitern

peerXref done:
x-ref list
    wz_Thermostat_Weather => wz_vT_Sensor1
    wz_vT_Sensor1 => wz_Thermostat_Weather

6. Gemessene Temperatur vom 1w DS1820 dem virtuellen HM Sensor übergeben. Ich mache das alle zwei Minuten per at:

Code Auswählen Erweitern

define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }

Fertig.

Wenn es bei dir klemmt, poste doch mal die Ausgaben von:

Code Auswählen Erweitern


list <dein_virtuelles_HM_Device>
list <dein_virtueller_temperatur_Sensor>
list <dein_RT_DN>_Weather

Gruß
Tobi

[der2of6]

6. Gemessene Temperatur vom 1w DS1820 dem virtuellen HM Sensor übergeben. Ich mache das alle zwei Minuten per at:

Code Auswählen Erweitern

define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }

Hallo Tobi,
Danke für deine schnelle Hilfe. Ich wollte den DS1820 mit mit dem virtuellen Sensor koppeln, das macht natürlich keinen Sinn.

Ich habe jetzt nur noch ein kleines Problem: Wenn ich o.g. Zeile in die Config einfüge, kommt beim 2. Teil

Code Auswählen Erweitern

define at_wz_vT at +*00:02 { my $T=(ReadingsVal("DS18B20_E43A56050000","temperature",20.0));; fhem "set wz_vT_Sensor1 virtTemp "$T} ein Fehler:

at_wz_vT already defined, delete it first
Unknown command fhem, try help.

Von den Klammern und "" her scheint der Befehl richtig zu sein.


Gruß,
Sebastian

[tpm88]

Hallo Sebastian,

stimmt - zumindest den

Code Auswählen Erweitern

Unknown command fhem, try help.

bekomm ich auch.

In jedem Fall funktioniert folgendes Vorgehen - und zwar über die Eingabe im Kommandofeld vom FHEMWEB Frontend. Ich editiere eigentlich grundsätzlich nicht direkt in der fhem.cfg...

Ggf. das at_wz_vT vorher noch einmal per delete löschen.

Code Auswählen Erweitern

define at_wz_vT at +*00:02 {}

Anschließend auf der Detailseite des gerade angelegten leeren at "DEF" anklicken und im Editor die eigentlichen Perl Kommandos in die geschweiften Klammern einfügen und per modify und anschliessendem save "festzurren"...

DEF:

Code Auswählen Erweitern

{ my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }

Tobi

[der2of6]

Hallo Tobi,
jetzt scheint es zu laufen, ich habe alle 2 Mintuen folgendes im Log:

2014.12.22 12:27:15 3: CUL_HM set wz_vT_Sensor1 virtTemp 20.9375
2014.12.22 12:29:15 3: CUL_HM set wz_vT_Sensor1 virtTemp 20.9375
2014.12.22 12:31:15 3: CUL_HM set wz_vT_Sensor1 virtTemp 20.875
2014.12.22 12:33:15 3: CUL_HM set wz_vT_Sensor1 virtTemp 20.9375

Das peering schaut gut aus:

peerXref done:
x-ref list
    wz_vT_Sensor1 => Bad.Heizung.IST  (Weather Channel des Thermostat)

Nur das Senden der Temperaturen scheint noch nicht zu laufen. Das sollte ich doch auch im Log sehen können?

Vg
Sebastian

[frank]

Das peering schaut gut aus:

wenn das alles ist, fehlt der rückkanal. ein fehler sollte dann bei hminfo configcheck auftauchen.

gruss frank

[der2of6]

Hallo Frank,
Danke für den Hinweis. Der Rückkanal war nicht vorhanden.
Nachdem ich das ganze nochmal probiert habe, übernimmt das Thermostat jetzt tatsächlich die Daten vom 1-Wire sensor.

Vielen dank euch beiden für die schnelle und kompetente Hilfe.

[Ascos]

Hi,

Ich habe 3 Lacrosse Sender und 3 Homematic Heizungsthermostate.
Die habe ich nach dieser Anleitung verbunden.
Bei zweien klappt alles einwandfrei, aber bei einem nicht.
Hier übernimmt der Weather Channel irgendwann die Werte aus dem virtuellen Sensor nicht mehr.
Meist läuft es ein paar Stunden, dann springt das Thermostat wieder auf den internen Fühler.
Im Display fängt dann auch das Antennen Symbol an zu blinken, was ja normalerweise dauerhaft leuchtet.

Im virtuellen Sensor sind alle Werte jeweils richtig übergeben, es hängt also irgendwo zwischen dem Sensor und dem Thermostat.
Leider bin ich noch total neu, bin für jede Hilfe dankbar.

Viele Grüße
Ascos

[tpm88]

Hi,
ein blinkendes Antennensymbol bedeutet  laut Manual eine Kommunikationsstörung zu einem Peering Partner. Bei virtuellen Sensor ist das das HM IO Device des FHEM Servers.

Wie sind denn die rssi Werte für dieses Thermostat?

Tobias


Gesendet von iPad mit Tapatalk

[sixpack]

Hallo,

ich habe das nun auch implementiert und ein ähnliches Problem, Situation:

• Im WZ 3 Thermostate mit einem Lacrosse
• Im BZ 1 Thermostat mit einem Lacrosse

Alle 4 RTs nehmen (ab und zu) die gesendete Temperatur nicht an, bislang (es läuft seid Sonntag) sehe ich hier keinen Zusammenhang / Regelmäßigkeit.

Die RTs "fangen" sich nach einiger Zeit (Stunden / Minuten) wieder.
Die RSSIs liegen alle zwischen: -56 & -62 (Wohnzimmer) und bei -79 (Badezimmer)


Irgendwelche Ideen / Vorschläge?

[frank]

Irgendwelche Ideen / Vorschläge?

raw-messages loggen. was für ein system hast du? io-device, fhem-server. gibt es disconnects? der bad-rssi ist nicht berauschend.

[sixpack]

Hi,

danke für das schnelle Feedback:

System Rpi, mit USB LAN Adapter für HM & Jeelink für LaCrosse, zumindest im normalen Log sehe ich keine disconnects.

Ich bin am Freitag wieder zu Hause und werde mal:

• Placement des HM dongles optimieren um den Empfang zu verbessern
• Jeelink und HM dongle räumlich weiter trennen
• RSSIs loggen (vielleicht passiert da was)
• RAW loggen --> kann mir jmd einen hinweis geben was ich mir anschauen durchlesen muss (vorher)

Gruß

[Ascos]

Hi,
ein blinkendes Antennensymbol bedeutet  laut Manual eine Kommunikationsstörung zu einem Peering Partner. Bei virtuellen Sensor ist das das HM IO Device des FHEM Servers.

Wie sind denn die rssi Werte für dieses Thermostat?

Tobias


Gesendet von iPad mit Tapatalk

Hi,

bitte entschuldige, ich war die letzten Tage viel arbeiten und habe deine Antwort nicht gesehen.
Inzwischen ist es bei allen 3 Thermostaten, das sie ab und zu über den Tag hinweg die Verbindung verlieren, zumindest was den Temperaturkanal angeht.

Die RSSI Werte

Schlafzimmer

Code Auswählen Erweitern

rssi_HMLAN1 avg:-56.97 min:-64 max:-53 lst:-56 cnt:37
rssi_at_HMLAN1 avg:-59.08 min:-76 max:-54 lst:-61 cnt:2881

Bad

Code Auswählen Erweitern

rssi_HMLAN1 avg:-50.15 min:-53 max:-47 lst:-49 cnt:40
rssi_at_HMLAN1 avg:-53.48 min:-62 max:-51 lst:-53 cnt:2898

Küche

Code Auswählen Erweitern

rssi_HMLAN1 avg:-43.44 min:-52 max:-41 lst:-41 cnt:27
rssi_at_HMLAN1 avg:-47.1 min:-61 max:-45 lst:-45 cnt:2842

Nach ca. 30 -90 Minuten haben sie sich dann wieder gefunden.

Ich bin für jede Hilfe dankbar.

Viele GRüße
Ascos

[tpm88]

Hallo Ascos,

kurzzeitige Aussetzer (siehe meinen Beitrag weiter oben im Thread) oder auch aktuell hier (https://forum.fhem.de/index.php/topic,33631.msg260133.html#msg260133) kommen immer mal vor. So lange wie bei dir (30 - 90 Minuten) sollte es aber keinesfalls sein.

Schwierig - mir fallen im Moment ein paar Sachen ein, wo man mit der Fehlersuche beginnen könnte:
- hast Du disconnects / reconnects des HMLAN im Log? Ich sehe immer wieder Threads im Forum, wo der HMLAN CFG nicht stabil läuft. Ich selbst nutze einen HM CFG USB2.
- Firmware der RT-DNs (mit der alten 1.0 hatte ich auch größere Probleme, mittlerweile unter 1.4 läuft es sehr stabil)
- hast Du eine vccu eingerichtet? Wenn nein, solltest Du das tun.
- hast Du mal mit apptime über einen vernünftigen Zeitraum (z.B. 30 - 60min) gemessen, ob Du auffällige Hänger des FHEM Servers beobachtest
- meldet der Action Detector in den Zeiträumen, wo die Temperaturen _nicht_ übertragen werden, Thermostate als missing?
- zeigt der HMinfo protoEvents Auffälligkeiten (Resends, NACK, etc.)
- FHEM auf neuestem Stand?

Wie ich auch in dem anderen Beitrag geschrieben habe, ist das Timing bei HomeMatic kritisch. Sehr sporadisch habe ich auch einmal einen kurzen Aussetzer, der aber immer nach dem nächsten Aufwachen des Thermostats (ca 3min später) wieder behoben ist.

Wenn obige Anregungen kein Problem ans Licht bringen, hilft nur Logging auf (raw) Paketebene. Dann müsstest Du Martin bitten, den raw Packet Trace zu analysieren.

Gruß
Tobias