Hallo zusammen,
ich konnte leider im Forum nix finden, daher mache ich einen neuen Thread auf.
Wie ich öfter gelesen habe, kann man die Temperatur eines 1-Wire-Sensors auf das Homematic-System abbilden. Leider habe ich bisher noch nirgendwo gelesen, wie das geht.
Also: wie erreiche ich, dass der RT entsprechend der vom DS18B20 erfassten Temperatur regelt?!
Jetzt schon einmal vielen Dank für eure Hilfe!
Viele Grüße
Bene
P.S.: da es sowohl 1-wire als auch Homematic betrifft, musste ich mich für ein Unterforum entscheiden... ;-D
Hallo Bene,
was ist schon das richtige Forum. 1-wire liefert "nur" die temperaturen.
HM muss ein verfahren finden, diese Werte als proxy an den RT zu senden.
Ich hatte dies bislang verschoben... um es einzubauen brauche ich noch logs von Usern, die einen RT mit HM-externen sensor betreiben. Diese müssten logs schicken vom Sensor und RT.
Ausserdem ein list der RT kanäle.
Kann das jemand hier einstellen?
Ein Problem könnte jedoch die Performance des HMLAN werden. Der sendet je Stunde nur eine begrenzte Anzahl messages. Das könnte ein engpass werden - aber schauen wir einmal. Cul ist dann wieder anders.
Gruss Martin
Hallo Martin,
danke für deine schnelle Antwort. Es ist schön, zu sehen, dass eine Frage wahrgenommen und beantwortet wird. Auch, wenn die Antwort nicht immer nach meinem Geschmack ist (sein kann).
Welche RT-Channel meinst du? Die vom Stellantrieb (HM-CC-RT-DN)? Problematisch dürfte ja sein, dass die zum Stellantrieb passenden Wandthermostate (http://www.eq-3.de/sensoren-detail/items/homematic-funk-wandthermostat-aufputzmontage.html) laut eQ-3 erst ab 03/2014 lieferbar sind....
Wenn ich irgendwas tun kann, was es dir einfacher macht, sag einfach Bescheid.
Gelesen habe ich von dieser Möglichkeit übrigens hier (http://www.fhemwiki.de/wiki/COC_und_1-wire).
Zitat von: FHEM-WikiIn der Firmware des COC ist eine Möglichkeit enthalten, die 1-Wire-Temperatursensoren DS18S20 in das Homematic-Protokoll zu mappen
Daher ging ich davon, dass diese Möglichkeit schon besteht - aber nun freue ich mich auf das, was kommen mag ;-D
Viiiieeeelen Dank für deine Arbeit und Mühe!!
Beste Grüße
Bene
Hallo Bene,
für den RT kann man als externes Thermostat quasi jeden HM temp-fühler nehmen (jedenfalls sind schon einige in Betrieb).
Was ich brauche ist das Verfahren, wie sie den RT aufwecken. Danach sind nur noch die Daten in das Format zu pressen und zu senden.
Da ich aber keinen Fühler habe kann ich es nicht rausmessen.
Wir brauchen also hilfe von einem, der es mit einem HM-sensor betreibt.
Das TC-IT... ist nicht nur ein temp-fühler sondern - wie ich es sehe eine Art Zentrale und fernbedienung. "nur"- Thermostat geht schon jetzt
Gruss Martin
Zitat von: martinp876 am 14 Dezember 2013, 08:43:08
Ich hatte dies bislang verschoben... um es einzubauen brauche ich noch logs von Usern, die einen RT mit HM-externen sensor betreiben. Diese müssten logs schicken vom Sensor und RT.
Ausserdem ein list der RT kanäle.
Kann das jemand hier einstellen?
Grüezi Martin,
Habe HM-SEC-RHS's im Einsatz. Falls diese als Sensoren reichen, schaffe ich mir gerne einen RT an um die nötigen Daten zu liefern.
Gruss
Marcel
Hallo Marcel,
nein, ein RHS sendet sicher burst. Es muss ein Wetter-sensor sein.
Evtl ist das Verfahren an TC/VD angeleht. Eine liste von messungen wäre hilfreich, dann kann man es nachrechnen - min 20-30 wetter-daten.
Gruss Martin
Grüezi Martin,
Too bad, too sad; habe gehofft, dass ich auf diese Art meine "Schuld" gegenüber der Gemeinschaft etwas abtragen könnte.
Der HM-TC-IT-WM-W-EU ist bei meinem Hoflieferanten hier in der Schweiz ab dem 17.1.14 verfügbar (und das ist ja schon bald). Falls das dient könnte ich ihn mit dem HM-CC-RT-DN bestellen (haben nur ein kleines Kontingent von noch 30 verfügbaren Stück für den Januar - die nächsten 48 Stk werden dann im März erwartet).
Gruss
Marcel
ZitatGelesen habe ich von dieser Möglichkeit übrigens hier.
Hi Bene,
das ist ein Missverständnis: Dieses "Abbilden" bezieht auf "HMS" und nicht "HM". In COC oder auch CUNO gibt es einen Firmwareteil, der 1-Wire einlesen kann und die Temperaturdaten als "HMS- Sensoren" ausgibt. Also für FHEM so tut als seien es nicht 1- Wire, sondern HMS- Sensoren. Diese Variante ist allerdings nicht sehr stabil. Mit max. 10 Sensoren sollte es gerade noch so gehen. Außerdem ist die Stromversorgung des Busses nicht optimal. Siehe auch im WIKI bei 1- Wire.
Wenn man sowas nutzt, kann man mit den gemessenen Temperaturen natürlich alles mögliche steuern und regeln. Auch HM- Komponenten.
Gruß
Frank
Hallo Martin,
Ich habe einen RT zusammen mit einem HM-WDS40-TH-I. Könnte man damit was anfangen? Wenn ja: Was genau brauchst Du?
Gruß,
Thorsten
Hi Throsten
einfach loggen
attr global verbose 1
attr global mseclog 1
attr <hmlan> logIDs all,sys
oder
attr <hmlan> logIDs <hmId_rt>,<hmId_TH_i>
danke Martin
Hi,
jetzt habe ich mal knapp 20 Minuten mitgeschrieben:
Hier der Auszug aus dem Logfile:
2014.01.05 12:39:30.337 0: HMLAN_Parse: HMLAN1 R:E21FBB2 stat:0000 t:507E118F d:FF r:FFC9 m:6C 8610 21FBB2 000000 0AA8D40F0011
2014.01.05 12:40:24.660 0: HMLAN_Parse: HMLAN1 R:E1F4CB9 stat:0000 t:507EFC43 d:FF r:FFCD m:C3 8670 1F4CB9 000000 00D431
2014.01.05 12:41:31.662 0: HMLAN_Parse: HMLAN1 R:E21FBB2 stat:0000 t:507FF601 d:FF r:FFC9 m:6D 8610 21FBB2 000000 0AA8D40F0011
2014.01.05 12:42:30.163 0: HMLAN_Parse: HMLAN1 R:E1F4CB9 stat:0000 t:5080E694 d:FF r:FFCD m:C4 8670 1F4CB9 000000 00D431
2014.01.05 12:44:22.087 0: HMLAN_Parse: HMLAN1 R:E21FBB2 stat:0000 t:50829BD8 d:FF r:FFC9 m:6E 8610 21FBB2 000000 0AA8D40F0011
2014.01.05 12:45:25.416 0: HMLAN_Parse: HMLAN1 R:E1F4CB9 stat:0000 t:50839342 d:FF r:FFCD m:C5 8670 1F4CB9 000000 00D332
2014.01.05 12:47:01.088 0: HMLAN_Parse: HMLAN1 R:E21FBB2 stat:0000 t:50850908 d:FF r:FFC7 m:6F 8610 21FBB2 000000 0AA8D30F0011
2014.01.05 12:48:06.168 0: HMLAN_Parse: HMLAN1 R:E1F4CB9 stat:0000 t:50860749 d:FF r:FFCD m:C6 8670 1F4CB9 000000 00D332
2014.01.05 12:49:25.590 0: HMLAN_Parse: HMLAN1 R:E21FBB2 stat:0000 t:50873D93 d:FF r:FFCC m:70 8610 21FBB2 000000 0AA8D30F0011
2014.01.05 12:50:32.421 0: HMLAN_Parse: HMLAN1 R:E1F4CB9 stat:0000 t:508842AC d:FF r:FFCC m:C7 8670 1F4CB9 000000 00D231
2014.01.05 12:51:35.843 0: HMLAN_Parse: HMLAN1 R:E21FBB2 stat:0000 t:50893A72 d:FF r:FFC7 m:71 8610 21FBB2 000000 0AA8D20F0011
2014.01.05 12:52:44.173 0: HMLAN_Parse: HMLAN1 R:E1F4CB9 stat:0000 t:508A4567 d:FF r:FFCD m:C8 8670 1F4CB9 000000 00D232
2014.01.05 12:54:35.592 0: HMLAN_Parse: HMLAN1 R:E21FBB2 stat:0000 t:508BF8B2 d:FF r:FFC6 m:72 8610 21FBB2 000000 0AA8D20F0811
2014.01.05 12:55:45.676 0: HMLAN_Parse: HMLAN1 R:E1F4CB9 stat:0000 t:508D0A80 d:FF r:FFCD m:C9 8670 1F4CB9 000000 00D232
2014.01.05 12:57:20.846 0: HMLAN_Parse: HMLAN1 R:E21FBB2 stat:0000 t:508E7E4D d:FF r:FFC9 m:73 8610 21FBB2 000000 0AA8D20F1711
Falls das nicht sowieso durch das Log klar ist: 1F4CB9 ist der Temperatursensor, 21FBB2 ist der RT.
Hier ist der Auszug aus der Logdatei vom Sensor:
2014-01-05_12:38:05 og_wz_Temperatur temperature: 21.2
2014-01-05_12:38:05 og_wz_Temperatur humidity: 49
2014-01-05_12:38:05 og_wz_Temperatur T: 21.2 H: 49
2014-01-05_12:40:24 og_wz_Temperatur temperature: 21.2
2014-01-05_12:40:24 og_wz_Temperatur humidity: 49
2014-01-05_12:40:24 og_wz_Temperatur T: 21.2 H: 49
2014-01-05_12:42:30 og_wz_Temperatur temperature: 21.2
2014-01-05_12:42:30 og_wz_Temperatur humidity: 49
2014-01-05_12:42:30 og_wz_Temperatur T: 21.2 H: 49
2014-01-05_12:45:25 og_wz_Temperatur temperature: 21.1
2014-01-05_12:45:25 og_wz_Temperatur humidity: 50
2014-01-05_12:45:25 og_wz_Temperatur T: 21.1 H: 50
2014-01-05_12:48:06 og_wz_Temperatur temperature: 21.1
2014-01-05_12:48:06 og_wz_Temperatur humidity: 50
2014-01-05_12:48:06 og_wz_Temperatur T: 21.1 H: 50
2014-01-05_12:50:32 og_wz_Temperatur temperature: 21.0
2014-01-05_12:50:32 og_wz_Temperatur humidity: 49
2014-01-05_12:50:32 og_wz_Temperatur T: 21.0 H: 49
2014-01-05_12:52:44 og_wz_Temperatur temperature: 21.0
2014-01-05_12:52:44 og_wz_Temperatur humidity: 50
2014-01-05_12:52:44 og_wz_Temperatur T: 21.0 H: 50
2014-01-05_12:55:45 og_wz_Temperatur temperature: 21.0
2014-01-05_12:55:45 og_wz_Temperatur humidity: 50
2014-01-05_12:55:45 og_wz_Temperatur T: 21.0 H: 50
2014-01-05_12:58:32 og_wz_Temperatur temperature: 21.0
2014-01-05_12:58:32 og_wz_Temperatur humidity: 50
2014-01-05_12:58:32 og_wz_Temperatur T: 21.0 H: 50
..und hier vom RT:
2014-01-05_12:37:06 og_ku_Heizung battery: ok
2014-01-05_12:37:06 og_ku_Heizung batteryLevel: 3 V
2014-01-05_12:37:06 og_ku_Heizung measured-temp: 21.2
2014-01-05_12:37:06 og_ku_Heizung desired-temp: 21
2014-01-05_12:37:06 og_ku_Heizung actuator: 0 %
2014-01-05_12:39:30 og_ku_Heizung battery: ok
2014-01-05_12:39:30 og_ku_Heizung batteryLevel: 3 V
2014-01-05_12:39:30 og_ku_Heizung measured-temp: 21.2
2014-01-05_12:39:30 og_ku_Heizung desired-temp: 21
2014-01-05_12:39:30 og_ku_Heizung actuator: 0 %
2014-01-05_12:41:31 og_ku_Heizung battery: ok
2014-01-05_12:41:31 og_ku_Heizung batteryLevel: 3 V
2014-01-05_12:41:31 og_ku_Heizung measured-temp: 21.2
2014-01-05_12:41:31 og_ku_Heizung desired-temp: 21
2014-01-05_12:41:31 og_ku_Heizung actuator: 0 %
2014-01-05_12:44:22 og_ku_Heizung battery: ok
2014-01-05_12:44:22 og_ku_Heizung batteryLevel: 3 V
2014-01-05_12:44:22 og_ku_Heizung measured-temp: 21.2
2014-01-05_12:44:22 og_ku_Heizung desired-temp: 21
2014-01-05_12:44:22 og_ku_Heizung actuator: 0 %
2014-01-05_12:47:01 og_ku_Heizung battery: ok
2014-01-05_12:47:01 og_ku_Heizung batteryLevel: 3 V
2014-01-05_12:47:01 og_ku_Heizung measured-temp: 21.1
2014-01-05_12:47:01 og_ku_Heizung desired-temp: 21
2014-01-05_12:47:01 og_ku_Heizung actuator: 0 %
2014-01-05_12:49:25 og_ku_Heizung battery: ok
2014-01-05_12:49:25 og_ku_Heizung batteryLevel: 3 V
2014-01-05_12:49:25 og_ku_Heizung measured-temp: 21.1
2014-01-05_12:49:25 og_ku_Heizung desired-temp: 21
2014-01-05_12:49:25 og_ku_Heizung actuator: 0 %
2014-01-05_12:51:35 og_ku_Heizung battery: ok
2014-01-05_12:51:35 og_ku_Heizung batteryLevel: 3 V
2014-01-05_12:51:35 og_ku_Heizung measured-temp: 21.0
2014-01-05_12:51:35 og_ku_Heizung desired-temp: 21
2014-01-05_12:51:35 og_ku_Heizung actuator: 0 %
2014-01-05_12:54:35 og_ku_Heizung battery: ok
2014-01-05_12:54:35 og_ku_Heizung batteryLevel: 3 V
2014-01-05_12:54:35 og_ku_Heizung measured-temp: 21.0
2014-01-05_12:54:35 og_ku_Heizung desired-temp: 21
2014-01-05_12:54:35 og_ku_Heizung actuator: 8 %
2014-01-05_12:57:20 og_ku_Heizung battery: ok
2014-01-05_12:57:20 og_ku_Heizung batteryLevel: 3 V
2014-01-05_12:57:20 og_ku_Heizung measured-temp: 21.0
2014-01-05_12:57:20 og_ku_Heizung desired-temp: 21
2014-01-05_12:57:20 og_ku_Heizung actuator: 23 %
2014-01-05_12:59:51 og_ku_Heizung battery: ok
2014-01-05_12:59:51 og_ku_Heizung batteryLevel: 3 V
2014-01-05_12:59:51 og_ku_Heizung measured-temp: 21.0
2014-01-05_12:59:51 og_ku_Heizung desired-temp: 21
2014-01-05_12:59:51 og_ku_Heizung actuator: 23 %
Reicht das?
Gruß,
Thorsten
Hi Thorsten,
ja, danke. Damit kann ich einmal anfangen
Gruss Martin
Nur, dass es wisst! Ich lese mit und freue mich, dass es scheinbar voran geht! :-)
Vielleicht klappt es ja mit meinen DS18B20 als Raumthermostaten!
Jetzt schon vielen Dank für eure Mühe!
Gute Nacht!
Bene
hi,
leider kann ich das timing nicht auf die bekannten algorythmen mappen...
Gruss Martin
Bäääm, nach der Freude kommt der Tiefschlag... :o
Ist das die generelle Absage an meine Anfrage oder nur ein "Zwischentief"?
Viele Grüße
Bene
schwer zu sagen... mit dem VD klappt es auch noch nicht reibungslos...
Sag Bescheid, wenn Du noch mehr Daten brauchst. Ich kann auch mal versuchen, das Teil zu quälen, wenn das was bringen sollte (Sensor in den Kühlschrank oder Backofen oder zu weit weg oder...)
Hi Thorsten,
Aktuell ist es sehr einfach: Es gibt eine Formel von homegear, die zu einem Timing des VD passen soll. Wie die Jungs darauf gekommen sind ist unklar - sie könnten es etwas einfacher machen, was darauf hindeuted, dass es nicht aus dem sourcecode von HM ist.
Diese Formel passt nicht zum Timing des Temp-Fühlers.
Die Formel ist relativ komplex, daher kann ich sie nicht anpassen.
Ein Test mit dem RT steht noch aus...
Gruss Martin
Zitat von: martinp876 am 06 Januar 2014, 14:15:43Die Formel ist relativ komplex, daher kann ich sie nicht anpassen.
Liegt's an fehlenden mathematischen Fähigkeiten oder an was anderem? Schick die Formel mal rüber, vielleicht kann ich da helfen.
Die Formel ist:
# int32_t result = (((_address << 8) | messageCounter) * 1103515245 + 12345) >> 16;
# return (result & 0xFF) + 480;
Das Resultat sind die Anzahl der 250ms steps
zu beachten: es ist c-code, 32bit integer. Runden beachten. Perl schaltet gerne nach float, was die Berechnung unbrauchbar macht.
vom Ergebnis sind schlussendlich nur bit 16 bis 23 relevant. Damit kann man erst einmal
_address &= 0xffff
rechnen
Der Wert 12996205 = C64E6D ist auch uebertrieben und kann auf 24bit gestutzt werden, ohne das Ergebnis zu aendern. Also statt 1103515245 = 0x41c64e6d kann mit 12996205 = C64E6D gerechnet werden.
Das Prinzip waere, dass dem Empfaender das naechste aufwachen mitgeilt wird mittels messageNo und Sender-addresse (HMId). Der Empfaender sollte dann zu diesem Zeitpunkt aufwachen - leider kann man dies nicht sehen - man koennte es nur in Empfaenger messen.
Rechne ich dies noch fuer eine TC/VD beziehung stimmt es. Rechne ich es fuer eine TH/RT beziehung (sample von oben) stimmen die Werte nicht.
Hi,
ich glaube, mir fehlen da ein paar Grundlagen...
Erst einmal: Das 8) ist wahrscheinlich ein "8 )"
Ansonsten: Für was stehen die Variablen und wo findet man die Werte?
_address ist die ID des Device? Also 1F4CB9 bzw. 21FBB2 ?
Wo finde ich den messageCounter?
Gruß,
Thorsten
Hi Thorsten
der message-counter ist das byte vor der sende-ID
Die Adresse ist die sende-ID
und ja, shift-left acht
Gruss Martin
Hi,
ok, in diesem Beispiel:
2014.01.05 12:42:30.163 0: HMLAN_Parse: HMLAN1 R:E1F4CB9 stat:0000 t:5080E694 d:FF r:FFCD m:C4 8670 1F4CB9 000000 00D431
...ist der message-Counter "C4" und die sende-ID ist "8670" richtig?
Gruß,
Thorsten
Das würde mich auch mal etwas näher interessieren.
Ist irgendwo die Bedeutung der ganzen Logparameter dokumentiert?
2014.01.05 12:42:30.163 0: HMLAN_Parse: HMLAN1 R:E1F4CB9 stat:0000 t:5080E694 d:FF r:FFCD m:C4 8670 1F4CB9 000000 00D431
2014.01.05 12:42:30.163 log zeitstempel
0: verbose level des logs
HMLAN_Parse: vergebener Name - meist ds Modul indetifizierend
# von hier Parameter wie es der Entwickler einstellt
HMLAN1 R:E1F4CB9 stat:0000 t:5080E694 d:FF r:FFCD m:C4 8670 1F4CB9 000000 00D431
HMLAN1 name des IO device
R:E1F4CB9 kann ich nicht deuten
stat:0000 status info. Eintrag von HMLAN addiert für HMLAN<-> zentrale protokol. u.a. zur Fehler-erkennung
t:5080E694 zeitstempel des HMLAN
d:FF AES key zuordnung (ff: kein AES)
r:FFCD RSSI am HMLAN
m:C4 8670 1F4CB9 000000 00D431 message
C4 sequenz nummer (zur msg zuordnung)
86 message-flags (broadcast/needack/burst,...)
70 msgTyp
1F4CB9 msg src ID
000000 msg destination id (000000 bei broadcast)
00D431 message-typ spezifische daten/nettoinfo
Vielen Dank !!
Hi,
ich würde nochmal gerne auf die Sache mit der Formel zurückkommen. Soweit ich verstanden habe, ist das der Knackpunkt um nicht-HM Geräte als Temperatursensor einzubinden.
# int32_t result = (((_address << 8 ) | messageCounter) * 1103515245 + 12345) >> 16;
# return (result & 0xFF) + 480;
Ich habe immer noch nicht kapiert, was man als _address bzw. messageCounter einsetzen muss. Du schreibst:
Zitat von: martinp876 am 08 Januar 2014, 16:36:04
der message-counter ist das byte vor der sende-ID
Die Adresse ist die sende-ID
Tja, aber welches ist die sende-ID?
Könntest Du mal an dem Beispiel hier sagen, was _address ist und was messageCounter?
2014.01.05 12:42:30.163 0: HMLAN_Parse: HMLAN1 R:E1F4CB9 stat:0000 t:5080E694 d:FF r:FFCD m:C4 8670 1F4CB9 000000 00D431Gruß,
Thorsten
ZitatTja, aber welches ist die sende-ID?
sorry, dachte es ist klar. src = source = quelle = sender
1F4CB9 msg src ID
Abend,
ich habe mir das Problem mal näher angesehen. Mit etwas Statistik und ein paar mehr Daten bin ich da auch schon etwas weiter gekommen. Es sieht aus als wenn es eine Serie von 71 Schritten gibt die immer gleich sind im Timing. Grob sieht das Timing wie im Anhang aus. Eine Sequenz dauert ca 3,5 Std. Die Zeilen sind immer die Abstände zwischen zwei Nachrichten. Wo der Beginn der Sequenz ist müsste man dann mal rausfinden indem man einen Sensor neu peert und das dann mitschneidet.
Leider hatte ich nur Daten mit Genauigkeit von 1s. Ich schreibe aktuell mal die Raw Messages mit und werte das dann in ein paar Tagen aus damit das genauer wird.
Sequenz.txt = 2 Sequenzen die recht gut matchen
Sequenz_Full.txt = Die Sequenzen über 2 Tage. Da gibt es ein paar kurze Lücken. Die kommen von der Zeit wenn mein HMUSB neustartet. An sich sieht das aber durchgehend einheitlich aus.
Die Frage ist jetzt ob die Sequenz von der HMID abhängt oder bei allen Geräten gleich ist. Nur ein Gedanke. Ich habe leider keinen zweiten Tempsensor.
Gruß,
Jan
So ich habe das mal weiter angeschaut. Es scheint genau die Formel zu sein:
function length($addr, $cnt)
{
$min = 480;
$res = ((($addr<<8)|$cnt) * 1103515245 + 12345) >> 16;
return (($res & 0xFF) + $min)/4;
}
$addr = 0x1F4C66;
for ($cnt = 0x0; $cnt < 0x68; $cnt++) {
echo length($addr, $cnt). "\n";
}
Das erzeugt genau das gleiche Timing wie ich in der Sequenz sehe. Vermutlich ist die Länge Zufall.
Anhängend:
real.txt - Die gemessenen Timings
predict.txt - Das Timing nach Formel
Abweichung über 104 Messwerte: 1s. Ich denke das sollte ok sein.
Gruß,
Jan
Hi Jan,
kannst du einmal die rohmessages schicken? Gerne gezippt. Insbesondere wenn es mit HMUSB oder HMLAN aufgenommen wurde.
Die Berechnung habe ich schon für den den VD realisiert - das konnte man übernehmen.
Mit vorsicht ist die Berechnung in Perl zu sehen, da Perl in dieser Größenordnung rundet.
Unteressant ist die Formel sowieso. Da am Ende nur Bits 16-23 genutzt werden braucht man alles über Bit 24 nicht. somit kann man mit 12996205 anstelle von 1103515245 rechnen.
ohne rundungsprobleme sollte es so gehen
my $idl = hex(substr($dst,4,2))*256+$msgCnt;
my $lo = int(($idl*0x4e6d +12345)/0x10000)&0xff;
my $hi = ($hash->{helper}{vd}{idh}+$idl*198)&0xff;
my $nextTimer = (($lo+$hi)&0xff)/4 + 120;
Wäre gut (und logisch) wenn es hier genauso wie bei dem VD geht
Gruss Martin
Hi Martin,
ich hab das Perl Programm mal gegengetestet:
my $dst = "1F4C66";
for (my $msgCnt=0; $msgCnt<104; $msgCnt++) {
my $idh = hex(substr($dst,2,2))*20077;
my $idl = hex(substr($dst,4,2))*256+$msgCnt;
my $lo = int(($idl*0x4e6d +12345)/0x10000)&0xff;
my $hi = ($idh+$idl*198)&0xff;
my $nextTimer = (($lo+$hi)&0xff)/4 + 120;
print $nextTimer;
print "\n";
}
Das ergibt den gleichen Output. Sollte also gehen :-). Anhängend die Raw Messages seit heute Mittag.
EDIT: Eine Sache ist mir aufgefallen: Die HMID sollter hier nicht $dst sondern $src sein. Sprich ich verwende die HMID des Senders (Tempsensor) und nicht des Empfängers (HM-CC-RT-DN).
Gruß,
Jan
Hi Jan,
so - dann kann man man ans implementieren denken. Sollte so laufen wie beim VD. Es gibt also ein Kommando
virtTemp <temp>
damit setzt man die temperatur, die beim nächsten Aufwachen übertragen wird.
Das Kommando wird einem virtuellen Channel freigeschaltet wenn er mit min einem RT Channel 01 gepeert ist.
mit
virtTemp off wird alles gestoppt. ansonsten wird immer der aktuellen Wert übertragen.
Ok so weit?
Gruss Martin
Hi Martin,
das klingt gut! Ggf kann man direkt virtHumidity mitimplementieren. Ist ja praktisch das gleiche.
Gruß,
Jan
Hi,
cool, dass es tatsächlich weitergeht. Es wäre schon genial, wenn man günstigere (und kleinere!) Temperatursensoren verwenden könnte.
Von wegen virtHumidity: Welche Geräte können damit was anfangen?
Gruß,
Thorsten
Hi Thorsten,
vermutlich keine aktuell. Aber der Messagetyp enthält beide Informationen. Ist aber auch kein Problem wenn Humidity 0 ist.
Gruß,
Jan
Hi
Version 4768 hat es implementiert - bitte testen. Mit einem RT habe ich es noch nicht gepeert
Kommando ist virtTemp <value>.
Was soll ein virtHumidity bringen? Der einzige sinn von virtTemp ist der Anschluss von Fremddevices an Aktoren, die es verarbeiten können. Gibt es dies auch für humidity?
Gruss Martin
Hi,
ich werde das leider erst nächste Woche testen können, hab's mir aber fest vorgenommen...
Gruß,
Thorsten
wird dies dann auch mit dem S300TH (bzw. jedem Temperatursensor?) funktionieren, bzw. funktioniert dies schon?
Gruß,
Martin
Hi DosiRocker,
das wird mit jedem Gerät gehen, das in FHEM ausgelesen werden kann. Vorgehen ist dann so:
- Notify auf den echten Sensor legen
- Wenn sich der Wert ändert kommt der Notify und setzt den Wert auf das dummy device
- Das dummy Device schickt den letzten gesetzten Wert periodisch über Funk
Ich werde das am Wochenende testen wenn ich mir etwas Zeit dafür nehmen kann.
Gruß,
Jan
Zitat von: jab am 31 Januar 2014, 16:34:31
Hi DosiRocker,
das wird mit jedem Gerät gehen, das in FHEM ausgelesen werden kann. Vorgehen ist dann so:
- Notify auf den echten Sensor legen
- Wenn sich der Wert ändert kommt der Notify und setzt den Wert auf das dummy device
- Das dummy Device schickt den letzten gesetzten Wert periodisch über Funk
Ich werde das am Wochenende testen wenn ich mir etwas Zeit dafür nehmen kann.
Gruß,
Jan
das hört sich super an, danke für die Rückmeldung. Fast schon schade, daß ich ab morgen für ein paar Tage in Urlaub fahre.
Das dummy Device ist dann mit dem RT gepeert, oder; verstehe ich das so richtig?
Ich könnte evtl. ab Ende nächster Woche mittesten mit S300TH und DS18B20, wenn Bedarf besteht (und ihr Lust habt mir das Einrichten des Dummy Devices zu erklären) ;D
Martin
Hallo zusammen,
mit Freude verfolge ich die aktuellen Entwicklungen!
Es sollte selbstverständlich sein, dass ich als Tester zur Verfügung stehe, wa?!! :-)
Vielen Dank für eure Mühe!
Bene
Hi,
ich habe gerade gelesen, dass ein RT auch die Humidity eines externen Sensors auswerten kann - jedenfalls behauptet das ELV im Prospekt zum RT-TC.
Somit werde ich also die Humidity einbauen - scheint ja sinn zu machen.
Option wäre "on top" des temp sensors -humidity wird es also nicht ohne temp geben, temp abre ohen humidity
Gruss Martin
...und was macht der RT dann damit?
Abend,
so ich habe das bei mir mal ausprobiert. Funktioniert hervorragend bei mir! Jetzt brauche ich nur noch echte Temperatursensoren. Danke Martin!
Gruß,
Jan
Und den Dank reiche ich an Frank weiter - sehr präzises testing und Untersuchungen.
In Version 4780 gibt es jetzt auch virtHum...
Hi,
ich hab jetzt testweise einen RT-DN bestellt und würde gerne virttemp und virthum in Form von 1Wire Temperatur und Feuchtesensoren ausprobieren wollen, welche Geräte muss ich (virtuell) anlegen mit welchem Befehl an den RT peeren?
Danke und Gruß
Jens
Moin Jens,
Ich habe das hier beschrieben: http://forum.fhem.de/index.php/topic,19686.0.html
Vielleicht sollten wir mal einen Wiki Artikel zu den ganzen virtuellen Hm Aktoren und Sensoren erstellen.
Gruß
Jan
Hey Jan,
Klasse habe ich jetzt mal eingerichtet (virtTemp) und das notify auf den virtuellen Tempsensor funktioniert auch, wo sehe ich denn jetzt am RT, dass er die Temperaturwerte des 1Wire Sensors auch gefressen hat?
Gruß
Jens
der rt sendet dann als Messwert immer den des externen sensors. An seinen eigenen kommt man meines wissens nicht mehr ran
Hi Martin,
virtHum ist bisher noch nicht implementiert oder?
Gruß
Jens
Hi Jens
nicht?
sollte schon seit einigen Tagen funktionieren.
baue dir einen neuer virtTH oder lösche webCmd, speichere und reboote. Dann solltest du einen tempsonsot mit virtTemp und virtHum incl pull-down in webinterface haben
virtHum ist ein zusatzparameter zum temp-sensor.
Gruss Martin
Hey Martin,
ich habe mir analog der Beschreibung von Jan einen weiteren Sensor angelegt
define virtual_hum CUL_HM 100002
set virtual_hum virtual 1
rename virtual_hum_Btn1 virtual_hum_Sensor_Bad_klein
set virtual_hum_Sensor_Bad_klein peerChan 0 mein_rt single
bei
set virtual_hum_Sensor_Bad_klein virtHum <der Wert meines Feuchtesensors>
erhalte ich jedoch die Meldung, dass virtHum nicht verwendet wird und ich doch einen anderen Parameter virtTemp etc. wählen möge (Fehlermeldung gerade nicht mehr 100%ig im Kopf und derzeit kein Zugriff auf mein Fhem).
Gruß
Jens
dann schicke einmal die Meldung. Generell gibt es keinen hum-only sensor (kenne ich gerade nicht) also auch keinen virtuellen.
Der hum ist eine addition zum temp.
Man sollte aber hum setzen können - dann wird eben temp 0 mit übertragen
Hi,
Konnte vorhin nur kurz mit fhem arbeiten, hab vorher noch ein update force und shutdown restart gemacht.
Ganz verstehe ich noch nicht wo ich ein webcmd löschen soll? Hab es mal am Sensor gemacht aber dort kein Pulldown-Menü im fhemweb erhalten...
Auch sieht die Meldung jetzt anders aus:
2014.02.07 00:38:12.476 3: set virtual_hum_Sensor1 virtHum 50.6990495667652 : level between 0 and 99 or 'off' allowed
wo am RT müsste man denn dann den Luftfeuchtewert finden?
Gruß
Jens
Hi Martin,
zudem erhalte ich in meinen Logs folgende Meldungen von dem virtuellen Temperatursensor
virtualTC timer off by:28191 (wobei die Zahl sich bei jeder neuen Meldung erhöht)
Ist hier etwas aus dem Sync geraten?
Gruß
Jens
Hi Jens
mit so vielen nachkommastellen habe ich nicht gerechnet. V4381.
das mit dem timer gesagt, dass der Aktor nicht antwortet
Gruss Martin