Originally posted by: <email address deleted>
Hallo Community,
ich habe folgende fhem.cfg
...
define CUL1 CUL /dev/ttyACM0@9600 1234
attr CUL1 room global
define CUL2 CUL /dev/ttyACM1@9600 2345
attr CUL2 rfmode HomeMatic
attr CUL2 room global
...
define autocreate autocreate
...
define HM01 CUL_HM 1506FB
attr HM01 devInfo 010100
attr HM01 firmware 1.8
attr HM01 hmClass unknown
attr HM01 model HM-CC-VD
attr HM01 room CUL_HM
attr HM01 serialNr HEQ0238507
attr HM01 subType unknown
define FileLog_HM01 FileLog /var/log/fhem/HM01-%Y.log HM01
attr FileLog_HM01 logtype text
attr FileLog_HM01 room CUL_HM
Wie zu erkennen ist, handelt es sich bei dem erkannten Gerät um einen
HM-CC-VD Stellantrieb. Einen HM-CC-TC will ich nicht benutzen. Sondern
möchte die Stellantriebe direkt ansprechen.
Nach dem Pairen zeigt mir fhem im Webinterface: MISSING ACK an. Meint
fhem, dass ihm ein ACK vom Stellantrieb fehlt oder andersrum?
Wenn ich die Antriebe direkt steuern will 0-99% Öffnung. Muss ich das
über den set raw Befehl des definierten devices machen? Bzw. Geht das
überhaupt? Mit den fhtv8-Antrieben hatte das wunderbar funktioniert
(Diese werden parallel mit dem definierten CUL1 gesteuert).
Schonmal vielen Dank für die Hilfe! Kann ich noch irgendwelche Infos
liefern?
Viele Grüße
Hubert
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 27.10.2011 um 23:33 schrieb Rudolf Koenig:
>> Bzw. Geht das überhaupt?
>
> Nicht dass ich wuesste. Der HM-CC-VD wird z.Zt. nur "verstanden". Da muesste
> man wohl die actuator Befehle der HM-CC-TC aussenden, und vorher muss das
> Pairing klappen.
Das kann doch nicht so schwer sein, ich sehe doch schon die Befehle vom HM-CC-TC zum HM-CC-VD. Und bald ist ja auch Heizperiode.
Falls das keine macht, kümmer ich mich nach dem Urlaub rum, ETA frühestens 1.12...
Grüße
Oskar
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On Oct 28, 11:28 pm, Jan-Hinrich Fessel
wrote:
> Das kann doch nicht so schwer sein, ich sehe doch schon die Befehle vom HM-CC-TC zum HM-CC-VD.
Hallo Oskar,
Kannst du mir vielleicht ein Logfile von diesen Befehlen zukommen
lassen? Ich habe leider nur ein HM-CC-VD. Dann könnte ich schonmal
etwas experimentieren.
Viele Grüße,
Hubert
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Moin!
Also ich habe mir jetzt mal einen TC besorgt. Also das mitloggen hat
wunderbar funktioniert. doProtocolEvents trägt alles schön in meine
Datenbank ein (DBLog). Ich habe dann einfach per "set raw" den Befehl
zum Ansteuern des HM-CC-VD's genommen den der HM-CC-TC gesendet hat
und habe die Sender-Adresse auf die des CULs geändert.
Und siehe da: Der Motor reagiert sofort und ohne Verzögerung! Und
stellt das Ventil auf die übertragene Prozentzahl (Hex als 0-255) ein.
Jedoch gibt es jetzt noch das Problem mit dem Sync. Der Sync klappt,
geht jedoch nach kurzer Zeit wieder verloren (ca. 5min). Ich habe dann
bemerkt, dass der TC als "Keep-Alive" einfach alle paar Minuten das
Ventil erneut einstellt. Hat sich der Wert nicht geändert, dann wird
der letzte Wert nochmal gestellt.
Wenn ich dieses Verhalten mit dem CUL nachstelle, dann verliere ich
leider trotzdem den Sync. Habe auch gesehen, dass sich der HM-CC-VD
beim Antworten anders verhält. Dem HM-CC-TC sendet er direkt
adressiert eine Rückmeldung. Wenn ich das Ventil vom FHEM ansteuere,
dann sendet er danach irgendwie einen Broadcast.
Soviel zum aktuellen Stand. Fazit: Ventil vom FHEM aus stellen
funktioniert, jedoch gibt es mit dem Sync noch Probleme. Man muss den
FEHM irgendwie dazu bringen sich wie ein HM-CC-TC zu verhalten evtl..
PS: Der HM-CC-TC ist ein sehr blöd designtes Gerät.
vG
Hubert
On Oct 27, 10:33 pm, Rudolf Koenig wrote:
> > Bzw. Geht das berhaupt?
>
> Nicht dass ich wuesste. Der HM-CC-VD wird z.Zt. nur "verstanden". Da muesste
> man wohl die actuator Befehle der HM-CC-TC aussenden, und vorher muss das
> Pairing klappen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Hallo Hubert,
Kannst Du uns das bitte nochmal langsam und genau erklaeren:
Ich formuliere mal vor :)
- Du hast via "set myTC raw xxxx" in fhem ein Befehl abgesetzt.
xxx ist die Raw-Meldung aus dem Log, wobei (NUR) die Adresse des TC durch
die CUL-HM Adresse ersetzt wurde. Kannst Du bitte es uns konkret zeigen?
Wenn ja, dann hast Du damit de-fakto im Namen von CUL eine Nachricht an das
VD gesendet. Komisch: der VD sollte mit dem TC gepaart sein, und von anderen
nichts uebernehmen.
- Dieser wurde _SOFORT_ vom VD empfangen und umgesetzt.
Wieder komisch: ich dachte das VD schlaeft X Sekunden, und wacht synchron mit
dem TC auf. Die Fhem-Kommunikation mit der TC laeuft so ab, dass fhem auf
eine TC->VD Nachricht wartet, und danach sofort die gepufferten Befehle
vorliest. Wenn das nicht innerhalb einer Sekunde (oder so) passiert, dann
pennt das TC schon wieder, und hoert auf nix. Oder irre ich mich?
- Wieso hast Du ein Problem mit dem Sync? Wie stellst Du sicher dass Du die X
Sekunden einhaeltst? Und was ist X eigentlich genau? Verwendest du beim
senden ++ ? Damit wird der HM Nachrichtenzaehler hochgezaehlt, sonst zaehlt die
Nachricht als Duplikat und wird ignoriert.
> PS: Der HM-CC-TC ist ein sehr blöd designtes Gerät.
Meinst Du das Protokoll oder das Gehaeuse? Wenn ersteres, dann solltest Du das
FHT80b mal ansehen :)
Gruss,
Rudi
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Folgendes Setup:
VD1 gepaart mit TC
VD2 gepaart als DEV_HM_VD2 per autocreate / rename mit FHEM
Im Log geguckt was TC an VD1 schickt wenn er das Ventil einstellt.
Dann mit "set DEV_HM_VD2 raw AsXXXXXXXXXXXXXXXXXXXX" Das Verhalten
nachgestellt.
(Vom Log kopiert und Sender/Empfänger Adressen ausgetauscht. Also als
Sender der FHEM Hauscode und Empfänger der VD2 Code.)
Dann durch periodisches wiederholen des "set DEV_HM_VD2 raw" Befehls
versucht die Verbindung aufrecht zu halten. Wenn ich den VD2 mit FHEM
paare dann geht er nach kurzer Zeit auf 15% und verliert seine Antenne
und nimmt keine Befehle mehr an. Durch Drücken auf den Knopf am VD2
ist er dann wieder Empfangsbereit (Muss nicht nochmal gepairt werden).
Und nimmt wieder Befehle mit "set raw" an.
Gruss,
Hubert
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Durch druecken des Knopfes ist das VD wohl bis auf weiteres wach, und schlaeft
erst nach dem Empfang der ersten Nachricht ein, da es damit ja gesynct ist.
Vorschlaege zum Experimentieren:
- erst muesste man X (Abstand in Sekunden zw. Nachrichten) rauskriegen. Beim
FHT80b ist z.Bsp X = 115+(FHT-ID & 7)*0.5 Sekunde. Fuer genauere Zeitangaben
kann man "attr global mseclog" setzen.
- danach koennte man ein "at" basteln, um die Theorie zu verifizieren, und
dabei verwendet man "set raw" mit dem ++
- Wenn die Theorie bestaetigt ist, dann macht man daraus ein "richtiges" Fhem
Befehl. Das kann ich uebernehmen, falls Du dazu keine Lust verspuerst.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> - erst muesste man X (Abstand in Sekunden zw. Nachrichten) rauskriegen. Beim
> FHT80b ist z.Bsp X = 115+(FHT-ID & 7)*0.5 Sekunde. Fuer genauere Zeitangaben
> kann man "attr global mseclog" setzen.
Ich habe was gesammelt mit
echo "inform timer" | ncat fhemhost 7073 | grep "CUL_HM VD1 act"
und etwas vi-Akrobatik:
Zeitpunkt delta delta von delta
========================================
11:32:48.785
11:35:24.038 155.253
11:37:44.792 140.754 -14.499
11:39:51.045 126.253 -14.501
11:42:47.049 176.004 49.751
11:45:28.555 161.506 -14.498
11:47:55.558 147.003 -14.503
11:50:08.312 132.754 -14.249
11:53:10.567 182.255 49.501
11:55:58.321 167.754 -14.501
11:58:31.821 153.500 -14.254
12:00:50.825 139.004 -14.496
12:02:55.328 124.503 -14.501
12:05:49.583 174.255 49.752
12:08:29.336 159.753 -14.502
12:10:35.090 125.754 -33.999
12:13:30.343 175.253 49.499
12:16:11.098 160.755 -14.498
12:18:37.601 146.503 -14.252
12:20:49.605 132.004 -14.499
12:23:51.109 181.504 49.500
12:26:38.363 167.254 -14.250
12:29:11.116 152.753 -14.501
12:31:29.370 138.254 -14.499
12:33:33.373 124.003 -14.251
12:36:26.877 173.504 49.501
12:39:05.881 159.004 -14.500
12:41:30.385 144.504 -14.500
12:43:40.637 130.252 -14.252
12:46:40.392 179.755 49.503
12:49:25.646 165.254 -14.501
Kann mir bitte daraus jemand eine Formel basteln? Insb. haette ich gerne die
wiederkehrende 0.25 Abweichung und die -34 erklaert bekommen. Und dann waere
noch die Frage, ob diese Zahlen TC-ID abhaengig sind.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Wie bekomme ich denn die Anzeige hin? Dann könnte ich es heute abend
mal bei mir testen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
So ich habe jetzt auch mal folgenden Test durchgeführt:
while(1) {
set VD_DEVICE raw AsXXXXXXXXXXXXXXXXXXXX (Random Stellwert)
sleep 1
}
Dann habe ich auf Antworten des VD's gefiltert. Bei mir ist er mit
2:50 min Abständen auf "Empfang" gegangen. Und hat natürlich auch die
Stellbefehle verarbeitet.
2011-11-07 16:36:44 CUL2 CUL CUL_HM RCV L:0E N:0A CMD:8102 SRC:149E69
DST:F12345 0101281022
2011-11-07 16:39:34 CUL2 CUL CUL_HM RCV L:0E N:0A CMD:8102 SRC:149E69
DST:F12345 01014E2026
2011-11-07 16:42:25 CUL2 CUL CUL_HM RCV L:0E N:0A CMD:8102 SRC:149E69
DST:F12345 0101281027
2011-11-07 16:45:15 CUL2 CUL CUL_HM RCV L:0E N:0A CMD:8102 SRC:149E69
DST:F12345 01014E2025
Hier ein Screenshot aus dem DBLog: http://dl.dropbox.com/u/18677544/VD.jpg
PS: Die Broadcast Nachrichten zwischen den 8102er CMDs kann ich mir
nicht erklären. Die kommen nicht wenn der VD mit dem TC gesynct ist.
Also eine Idee wäre eine Art Timer zu machen. Wenn man ein Recieve mit
CMD 8102 bekommt, dann setze einen Timer auf 2:45 und gehe für 10sec
auf Dauerfeuer mit aktuellem Wert.
Wenn ich den TC per screen /dev/CUL mitschneide, dann scheint er das
Ähnlich zu machen. Der sendet auch in Minuten-Abständen extrem viele
gleiche Befehle hinternander.
Ich vermute das das 8102 CMD im Payload auch noch irgendeine Timer
Info mitschickt? Zumindest scheint da ein Muster zu sein (Vgl. Oben im
Log).
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> ... und gehe für 10sec auf Dauerfeuer mit aktuellem Wert.
Sowas kommt nicht in meine Tuete.
> Wenn ich den TC per screen /dev/CUL mitschneide, dann scheint er das
> Ähnlich zu machen.
Kann ich nicht bestaetigen. Es wird immer nur eine Funknachricht abgesetzt.
> Ich vermute das das 8102 CMD im Payload auch noch irgendeine Timer
> Info mitschickt? Zumindest scheint da ein Muster zu sein (Vgl. Oben im
> Log).
Nope, die Nachrichten-Inhalte sind identisch (bis auf dem Nachrichtenzaehler).
Es muss ein Algo sein, der in den beiden Geraete (TC & VD) werkelt.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 08.11.2011 um 12:03 schrieb Rudolf Koenig:
>> ... und gehe für 10sec auf Dauerfeuer mit aktuellem Wert.
>
> Sowas kommt nicht in meine Tuete.
>
Wären ja auch komische Rauchwaren...
>
>> Wenn ich den TC per screen /dev/CUL mitschneide, dann scheint er das
>> Ähnlich zu machen.
>
> Kann ich nicht bestaetigen. Es wird immer nur eine Funknachricht abgesetzt.
>
Bei meinen auch.
>
>> Ich vermute das das 8102 CMD im Payload auch noch irgendeine Timer
>> Info mitschickt? Zumindest scheint da ein Muster zu sein (Vgl. Oben im
>> Log).
>
> Nope, die Nachrichten-Inhalte sind identisch (bis auf dem Nachrichtenzaehler).
Bei mir nicht.
Abstände:
Standard-Meldung:
2011.11.08 20:00:00 2: CUL_HM RCV L:0E N:47 CMD:8202 SRC:13F251 DST:15B50D 010100002A
4:55
5:03
5:08
5:15 - folgende Meldung:
2011.11.08 20:20:20 2: CUL_HM RCV L:0E N:4F CMD:8202 SRC:13F251 DST:15B50D 0101000029
Telegramm dann nach:
4:17
5:24
4:29
5:40
4:42
4:52
4:55
5:01
5:07 - jetzt wieder Telegramm:
2011.11.08 21:05:50 2: CUL_HM RCV L:0E N:61 CMD:8202 SRC:13F251 DST:15B50D 0101000029
dann wieder normales Antworttelegramm:
5:13
4:20
> Es muss ein Algo sein, der in den beiden Geraete (TC & VD) werkelt.
Wer weiss...
vielleicht gibt es auch einfach ein 60 Sekunden-Fenster, und der VD meldet, wenn man fast rausläuft...
Grüße
Oskar
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On Nov 8, 10:00 pm, Jan-Hinrich Fessel wrote:
> vielleicht gibt es auch einfach ein 60 Sekunden-Fenster, und der VD meldet, wenn man fast rausläuft...
Ich habe ja im Abstand von 1sec immer Befehle hingeschickt. Aber
gestellt hat sich der VD nur, wenn er auch ein RCV gesendet hat. Es
könnte natürlich sein, dass der VD sich nach dem Empfangen einer
Nachricht wieder für 2:50min schlaafen legt. Aber das eigentliche
Empfangsfenster größer ist.
Szenario:
1. VD synct sich mit FHEM und geht für ca. 128 (steht irgendwo im
Handbuch) auf Empfang am Anfang.
2. Nach Erhalt der ersten Stellung geht VD in Sleep für x (ca.
2:50min) Sekunden
3. VD geht nach x Sekunden für y Sec auf Empfang.
4. FHEM/TC sendet x Sekunden nach letzter erfolgreicher Sendung
erneut.
Ich werde beim nächsten Experimentieren mal gucken ob es so ein y
gibt. Also mal versuchen 2:55 / 3:00 / 3:05 min nach letzter
Erfolgreicher Sendung erneut zu senden.
Das wäre dann eine art Buffer für TC/FHEM. Wenn ein Senden fehlschälgt
hat er ein Fenster wo er es nochmal versuchen kann.
Grüße
Hubert
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> 2. Nach Erhalt der ersten Stellung geht VD in Sleep für x (ca.
> 2:50min) Sekunden
Nach meinen Messungen meine ich, dass X nicht konstant ist, siehe meine
Messreihe.
> 3. VD geht nach x Sekunden für y Sec auf Empfang.
Ich bin ueberzeugt, dass y <= 1 Sec ist, um die Batterie zu schonen. Das ist
bei dem Vorgaenger (FHT8v) definitiv der Fall.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Am 09.11.2011 um 08:29 schrieb Hubert Schreiner:
> On Nov 8, 10:00 pm, Jan-Hinrich Fessel wrote:
>> vielleicht gibt es auch einfach ein 60 Sekunden-Fenster, und der VD meldet, wenn man fast rausläuft...
>
> Ich habe ja im Abstand von 1sec immer Befehle hingeschickt. Aber
> gestellt hat sich der VD nur, wenn er auch ein RCV gesendet hat. Es
> könnte natürlich sein, dass der VD sich nach dem Empfangen einer
> Nachricht wieder für 2:50min schlaafen legt. Aber das eigentliche
> Empfangsfenster größer ist.
vielleicht war das nicht klar genug: Mein TC sendet immer nach mindestens 4:00 und maximal 5:30 Minuten ein Telegramm an die VD's und bekommt jedesmal ein ACK zurück.
> Szenario:
> 1. VD synct sich mit FHEM und geht für ca. 128 (steht irgendwo im
> Handbuch) auf Empfang am Anfang.
> 2. Nach Erhalt der ersten Stellung geht VD in Sleep für x (ca.
> 2:50min) Sekunden
> 3. VD geht nach x Sekunden für y Sec auf Empfang.
> 4. FHEM/TC sendet x Sekunden nach letzter erfolgreicher Sendung
> erneut.
>
> Ich werde beim nächsten Experimentieren mal gucken ob es so ein y
> gibt. Also mal versuchen 2:55 / 3:00 / 3:05 min nach letzter
> Erfolgreicher Sendung erneut zu senden.
Es gibt bestimmt ein y. Die Frage ist nur, woraus sich x und y berechnen, und ob die beim pairen festgelegt werden oder dynamisch von irgendwas abhängig sind. Der TC hat jedenfalls kein festes x...
Viel Erfolg!
Grüße
Oskar
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
On Nov 9, 9:51 am, Jan-Hinrich Fessel wrote:
> Es gibt bestimmt ein y. Die Frage ist nur, woraus sich x und y berechnen, und ob die beim pairen festgelegt werden oder dynamisch von irgendwas abhängig sind. Der TC hat jedenfalls kein festes x...
Also Fakt scheint zu sein, dass das Verhalten sehr Unterschiedlich ist
von Setup zu Setup. Dies würde auf eine dynamische Abhängigkeit
hindeuten. Ich werde mir den TC/VD Sync-Vorgang nochmal mitschneiden
und mal versuchen irgendwie das Payload zu analysieren...
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Bzw. Geht das überhaupt?
Nicht dass ich wuesste. Der HM-CC-VD wird z.Zt. nur "verstanden". Da muesste
man wohl die actuator Befehle der HM-CC-TC aussenden, und vorher muss das
Pairing klappen.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com