Kann mir jemand sagen, ob es einen Temperatursensor gibt, mit dem ich zwei HM-CC-RT-DN in einem Raum steuern kann.
Hi,
gibt mehrere, z.B. den hier (http://www.fhemwiki.de/wiki/HM-WDS40-TH-I_Funk-Temperatur-_Luftfeuchtesensor_innen). Man kann zwar einen RT nur mit jeweils einem Temp.-sensor peeren (macht auch Sinn, denn nach welcher Temp. soll denn sonst geregelt werde), aber es spricht nichts dagegen, mehrere RTs mit ein und demselben Temp.-sensor zu peeren.
Gruß
Thomas
Hi Thomas,
kannst du mir logs schicken?
List eines WDS40 - evtl gepeert mit mehreren RTs
roh-messages der Kommunikation WDS40/RT
Danke
Martin
@Tantor: Bevor du das mit dem HM-Sensor jetzt versuchst... ich werde das am Wochenende mal bei mir mit einer WDS40/RT-Kombination durchexerzieren/-probieren. Nicht, dass es da doch noch Probleme gibt. Laut Manuals soll das zwar funktionieren, aber wer weiß.
Sorry, dass ich mich evtl. zu weit aus dem Fenster gelehnt habe.
@Martin
du hast PM
Gruß
Thomas
Habe mir zwar schon einen Sensor bestellt, würde mich freuen, wenn du mich auf dem Laufenden halten würdest. Da ich erst vorgestern mit dem Thema FHEM angefangen habe, würde ich mich auch über deine Konfi freuen.
Hallo Martin,
da ich den PMs anscheinend keine Dateien anhängen kann, mache ich es doch hier im Thread.
Es schaut mM gut aus. Ist zwar etwas chaotisch (der WDS40, weil in dem stehen 2 Peers drin, die da überhaupt nichts zu suchen haben), aber es funktioniert. Der RT scheint vom WDS40 geregelt zu werden. Alle(?) Infos im beiliegenden Textfile.
Falls du noch was brauchst, melde dich, ich lasse die Testumgebung erst mal so stehen.
Edith hat mich gerade erinnert, dass du auch ein list vom WDS haben wolltest.
Jetzt bin ich gespannt ;)
Gruß
Thomas
Hallo Thomas
1) WDs40 peers
unklar. das Lesen der Config zeigt, dass der WDS40 gepeert ist mit
18:09:35
2236AC ch:01
2236AC ch:04
2236AC ch:05
peerIDs zeigen aber :
peerIDs 00000000,1B5B2101,1CFBB001,
und ein weiteres getConfig ist pending.
a) sind die peerIDs noch alt? Nach einem getConfig sollte der RT 3-mal auftauchen. Danach ein save wäre sinnvoll- zumindest das Attribut peerIDs korrigieren.
b) warum steht der RT 3-mal drin? Wie hast du gepeert - mit FHEM oder direkt?
c) falls die peers nicht absichtlich eingetragen wurden würde ich sie löschen - als channel 4 und 5. Die sind für teaming.
2) RT peers
der WDS ist nur auf Kanal 1 (Weather) eingetragen. Klingt gut für mich
4) WDS40 register
der WDS40 hat mehr register als aktuell gezeigt werden. Über die Bedeutung kann ich nur spekulieren. Es ist im bereich für "buttonLock", "anzeige oder LED-dauer" und transmission-mode. Aber das es ist, ist unklar.
Du kannst spielen mit
set UG.WaKue.ThermoHygro regBulk RegL_00: 05:xx
wobei xx ein hex-wert ist - aktuell auf 00, max ist ff. Die Adresse wird i.a. für leuchtdauer u.ä. verwendet
set UG.WaKue.ThermoHygro regBulk RegL_00: 0f:xx
hier ist i.a. button-lock einstellbar.
Die anderen beiden Register würde ich erste einmal nicht ändern.
Unklar ist, ob noch weitere Listen 'versteckt' sind
Du könntest ein
set UG.WaKue.ThermoHygro raw ++A001123ABC1ABEFB01040000000001
abschicken und loggen
dann ein
set UG.WaKue.ThermoHygro raw ++A001123ABC1ABEFB01042236AC0103
dann ein
set UG.WaKue.ThermoHygro raw ++A001123ABC1ABEFB01042236AC0104
Die letzten 3 versuchen zu Lesen - kann sein, dass der WDS nicht antwortet - dann ist eben nichts. Sie Ändern nichts am Device und dessen Einstellungen
4) Übertragung
der WDS sendet alles auf broadcast. Man kann nicht sehen, ob und wie er den RT aufweckt.
Ich werden es einmal simulieren - mal sehen, ob mein RT reagiert.
Gruss Martin
Hmmm...
alles klar ;) habe ich was zu tun, aber ...
mein RT zeigte gerade blinkende Antenne, den WDS40 konnte ich nicht mehr ansprechen, Batterien getauscht (waren unbelastet beide auf ~ 1,36 V) und siehe da, alles Bestens und die "Schattenpeerings" (die ich mir im Leben nicht hätte erklären können) sind ebenfalls verschwunden. Jetzt kann ich wohl weiter testen. Ich melde mich.
Hmmm... gerade mal die Logs vom WDS40 durchgesehen... da sind keinerlei "battery"-Meldungen drin, weder "ok" noch "low". Schau ich mir nochmal an, denn ich habe bisher an den default-Einstellungen meiner Logs nichts geschraubt, außer mit event-on-change (aber nicht am WDS40).
Schon mal Danke auf diesem Weg.
Gruß
Thomas
Hi,
sorry, ich mache mal kein edit meines vorherigen Beitrages, damit die Abonnenten dieses Threads auch was mitkriegen. Habe mal alles neu aufgesetzt und das Meiste von Martin umgesetzt (siehe anhängendes File). Das Peering sollte (nach dem Batteriewechsel im WDS40) nun auch sauber sein.
Gruß
Thomas
Hallo Thomas,
- ich kann keinen Batterie-status erkennen. Im Vergleich der beiden Logs kann ich nicht erkennen, dass ein Unterschied besteht.
- der WDS40 hat keine registerliste 01, 03 oder 04.
somit stellt sich die Frage, wozu der WDS40 gepeert werden kann. Er sendet nicht an die peerAdresse und hat keine erkennbaren Einstellungen den Peer betreffend.
Den Test zur Simulation eines temp-fühlers bin ich noch nicht gekommen.
Gruss Martin
Hmmm...
aber woher bekommt dann der RT in ClimRT_tr die Temperaturwerte vom WDS40?
Er regelt dann nämlich auch nach der Temperatur des WDS40. Ich hatte den WDS40 gestern Abend wieder in die Waschküche verpflanzt und mich heute morgen (bis jetzt gerade) über die Wärme im Arbeitszimmer gewundert, wo der RT momentan das Ventil steuert. Habe den ganzen Tag runtergeregelt und gerade eben erst mich erinnert, dass der WDS40 ja im Keller steht mit ca. 17 °C.
Siehe auch beigefügte Grafik, die Y2-Achsen haben aber eine unterschiedliche Skala.
Irgendetwas muss da sein, dass die Temperaturen des WDS40 in ClimTR_tr des RT auflaufen.
Soll ich dir den WDS40 für weitere Tests zuschicken? Ich kann ihn gerne eine Zeit lang entbehren.
Gruß
Thomas
Wie heißt dann der Befehl bzw. die Definition des HM-WDS40-TH-I um ihn mit einem HM-CC-RT-DN zu verbinden.
Weil *ich* mit den Peering Befehlen immer wieder von Neuem "auf Kriegsfuß stehe" (was ist Aktor/Sensor, was steht vorne im entsprechenden "set-Befehl", was steht hinten, welche Option wie "single" usw. ist wann anzugeben, welche(r) Channel müssen/können gepeert werden), mache *ich* das von Hand. Ist aber nicht die empfohlene Vorgehensweise.
Erst den RT (darf nicht mit Fhem gepairt sein, also notfalls resetten, ebenso den WDS40, da manuelles peeren nur klappt, wenn noch kein pairing aktiv ist) in den Anlernmodus versetzen und dann kurz den kleinen schwarzen Knopf am WDS drücken.
Gruß
Thomas
Hi,
a) warum der RT von WDS empfängt
der WDS sendet an broadcast. Der RT hört darauf - filtert nach dem bei ihm eingetragenen peer. Daher ist es kein Problem
b) warum der RT überhaupt empfängt
das habe ich noch nicht verstanden. Der RT wird (wahrscheinlich) nicht durch burst aufgeweckt. Evtl hat er eine wachphase und syncht sich auf den WDS... oder er ist immer wach .... oder der burst wird gesendet ohne dass ich es sehe (ist möglich)
c) warum peers beim WDS eingetragen werden
verstehe ich nicht. Ich gehe davon aus, dass es auch funktionieren würde, wären die Peers NICHT im WDS eingetragen (RT MUSS bestehen bleiben)
d) peering RT mit WDS40 ohne FHEM
hast du das so gemacht? Nur dies und das Ergebnis ist das, was wir gelesen haben? Auch nach XML macht es keinerlei Sinn den WDS mit etwas anderem zu peeren als mit Channel 01 (Weather)
e) peering RT mit WDS40 mit FHEM
set <wds40> peerChan 0 <rt_weather> single
sollte alles notwendige machen.
Um es in den WDS40 zu schreiben ist anlernen des selben notwendig, beim RT gibt es die bekannten modi.
=> kann das jemand probieren? Gibt es Probleme dabei?
Gruss Martin
Hej Martin,
ich hab hier einen WDS10 zum Testen herum liegen, aber wenn du willst, kann ich damit gerne mein Glück versuchen. :-)
Kann man die Verbindung in der Konfiguration des Thermostat sehen, wenn ja welcher Eintrag? Habe heute versucht eine neues Thermostat und ein resetetes Thermostat mit dem zurückgesetzten Thermometer zu peeren. Sah anfangs so aus, als hätte es funktioniert. Jedoch nachdem ich ins Webif reingeschaut habe, konnte ich beide Thermostate und das Thermometer sehen und in der Konfiguration ist nichts von einem Peering zusehen. Was sollte bei Weather in den Thermostaten stehen?
@ Mr.P.
wenn du einen WDs mit einem RT peerst
set <wds> peerChan 0 <rt_Weather> single
sollte der RT m.E. nach den Werten des WDS regeln. Es werden wohl auch dessen Readings als actual-remp angezeigt.
Stimmt das?
@tantor
die peers sind im Reading peerList zu sehen. Wenn dies leer ist wurde entweder kein getConfig ausgeführt oder die Liste ist leer.
Gruss Martin
Leider finde ich keine peerList. In den Readings steht nur "paired to". Mein WDS schaut dort auf meinen CUL. Habe auf beide Thermostate ein "set WDS peerChan 0 ..."durchgeführt und anschließend nach "get config" haben beide Thermostate unterschiedliche Informationsstände in den Readings.
Hallo,
Zitat von: martinp876 am 22 Dezember 2013, 16:37:19
...Es werden wohl auch dessen Readings als actual-remp angezeigt.
Stimmt das?
Die Temperatur des WDS40 taucht im Device als measured-temp und im Channel ClimRT_tr im state auf.
btw: du sagtest, dass mein WDS40 an broadcast sendet. Leider sehe ich nirgends in den Logs etwas davon. Das wundert mich etwas, weil ich von anderen Devices sehr wohl Informationen sehe, ob die an broadcast oder mein HMLAN1 senden (vor bzw. nach erfolgreichem Pairing).
Gruß
Thomas
Zitat von: tantor am 22 Dezember 2013, 17:24:21
Leider finde ich keine peerList.
Channel-Peerings tauchen in den jeweils gepeerten Channels auf. Schau mal im Channel 01 ("..._Weather") des RT nach. Dort findet sich mein WDS40 wieder.
Gruß
Thomas
Hallo,
@Martin: Gerade mal per Zufall in die "eventTypes"-Liste (also "et" von Rudolf) rein geschaut. Dort gibt es einen Event-Typ
UG.WaKue.ThermoHygro powerOn: -
neben den anderen
UG.WaKue.ThermoHygro Activity: alive
UG.WaKue.ThermoHygro IOerr
UG.WaKue.ThermoHygro MISSING ACK
UG.WaKue.ThermoHygro NACK
UG.WaKue.ThermoHygro R-burstRx: off
UG.WaKue.ThermoHygro R-pairCentral: 0x123ABC
UG.WaKue.ThermoHygro R-pairCentral: set_.*x123ABC
UG.WaKue.ThermoHygro ResndFail
UG.WaKue.ThermoHygro T: .* H: .*
UG.WaKue.ThermoHygro humidity: .*
UG.WaKue.ThermoHygro powerOn: - <<=== hier
UG.WaKue.ThermoHygro temperature: .*
Dieses "powerOn" finde ich nicht in den Internals/Readings meines WDS40 (welcher ja der UG.WaKue.ThermoHygro ist).
Gibt es dafür irgendeine Erklärung bzw. was hat es damit auf sich?
Gruß
Thomas
Hi Thomas,
ich habe den thSensor noch nicht an etwas anderes als broadcast senden sehen. Da in keinem der Readings ein "to" drin ist kann man also auch nicht sehen, wohin die Message geht. Da es bei den TH auch nur broadcast gibt (soweit ich es kenne..) ist es also auch ok.
wie erwähnt: warum peers im WDS eingetragen werden können erschliesst sich mir nicht - vielleicht kommen wir noch dahinter. Nihct verwechseln: den WDS als peer in einem Aktor eintragen ist schon wichtig!
powerOn
das Reading wird geschrieben, wenn ein pwerOn eines device erkannt wird. Da liegt erst einmal eine generelle Erkennung dahinter welche von vielen devices so gehandelt wird. Natürlich gibt es ein paar bekannte Ausnahmen, die wir speziell fangen.
Wenn nichts drin steht kann es sein, dass der WDS40 im Zeitraum einfach keinen powerOn hatte. Oder er schickt ein bisher unbekanntes pattern.
Du kannst einmal rohmessages einschalten und dem WDS die Batterien klauen. Dann natürlich zurückgeben, damit wir einen powerOn haben.
Generall könnte man darauf achten, dass es keinen powerOn gibt bzw einen Alarm senden, wenn dem so ist. Im Betrieb sollte das ja nicht vorkommen
Gruss Martin