HM-TC-IT-WM-W-EU: Funk-Wandthermostat

[betateilchen]

Nun wollte ich auch noch meinen an den RT gepeerten SC (Fenstersensor) mit dem TC peeren:
Das klappt irgendwie nur so halb. Ich kann den Peer im <SC> sehen (zusammen mit dem RT). Im TC_WindowRec fehlt der Peer allerdings.

Das peerChan scheint für den TC noch nicht vollständig implementiert zu sein. Das Peering mit einem Türsensor funktioniert aber trotzdem auch jetzt schon unter zwei Bedingungen:

1. Du richtest das peering per peerBulk ein
2. Der Türsensor sollte NUR an den TC gepeert sein und keinen zweiten Thermostaten als Partner haben

Kann man auch <RT_WindowRec> mit <TC_WindowRec> peeren? Ergäbe das Sinn?

Nein, das macht keinen Sinn.

[martinp876]

Ferner steht das Reading <TC_WindowRec>peerNeedsBurst im SC auf off. Setze ich den Befehl

set <SC> regSet peerNeedsBurst <TC_WindowRec> on

syntax:

regSet [prep|exec] <regName> <value> <peerChannel>
set <SC> regSet peerNeedsBurst on <TC_WindowRec>

Kann man auch <RT_WindowRec> mit <TC_WindowRec> peeren? Ergäbe das Sinn?

Peeren kann man nur einen Sender mit einem Empfaenger. Ein Channel ist immer nur eines. Der TC_WindowRec ist ein Empfaenger, also kann er nicht mit dem RT_WindowRec (auch Empfaenger) gepeert werden.

Du richtest das peering per peerBulk ein

geht nicht? ok - muss ich nachsehen

Gruss Martin

[betateilchen]

Hallo Martin,

wie werde ich die vielen Meldungen im Log wieder los?

Code Auswählen Erweitern


2014.02.13 22:34:09 0: HMLAN_Parse: HMUSB V:03C7 sNo:JEQ0534751 d:1DAFAC O:127000 t:152CBD06 IDcnt:0004
2014.02.13 22:34:13 0: HMLAN_Parse: HMUSB R:E1FCBBC   stat:0000 t:152CCD88 d:FF r:FFDB     m:49 8670 1FCBBC 000000 00CE3B
2014.02.13 22:34:16 0: HMLAN_Parse: HMUSB R:E20DACD   stat:0000 t:152CD61A d:FF r:FFCA     m:0B 8670 20DACD 000000 00354D
2014.02.13 22:34:34 0: HMLAN_Send:  HMUSB I:K
2014.02.13 22:34:34 0: HMLAN_Parse: HMUSB V:03C7 sNo:JEQ0534751 d:1DAFAC O:127000 t:152D1EBC IDcnt:0004
2014.02.13 22:34:59 0: HMLAN_Send:  HMUSB I:K
2014.02.13 22:34:59 0: HMLAN_Parse: HMUSB V:03C7 sNo:JEQ0534751 d:1DAFAC O:127000 t:152D807E IDcnt:0004


[frank]

wie werde ich die vielen Meldungen im Log wieder los?

attr <iodev> logIDs 0   =>  alle aus.

gruss frank

[betateilchen]

danke. Ich hatte schon versucht, das Attribut ganz zu löschen, aber irgendwie hat das gestern nicht funktioniert. Heute klappt das komischerweise.

[CQuadrat]

syntax:
Zitat
regSet [prep|exec] <regName> <value> <peerChannel>
set <SC> regSet peerNeedsBurst on <TC_WindowRec>

Zitat

Danke! Hat funktioniert. 
Wurde hier die Syntax mal geändert? Ich meine, ich hätte das vor ein paar Monaten noch anders gemacht...

Ferner habe ich noch Probleme beim Setzen von Registern beim TC: hier bekomme ich sehr oft ein NACK. Templisten und diverse Register, wie z.B. winOpnBoost, konnte ich noch gar nicht setzen/ändern.

[martinp876]

Wurde hier die Syntax mal geändert? Ich meine, ich hätte das vor ein paar Monaten noch anders gemacht...

paar Monate? so lange geht mein Gedaechtnis nicht zurueck

Ferner habe ich noch Probleme beim Setzen von Registern beim TC: hier bekomme ich sehr oft ein NACK. Templisten und diverse Register, wie z.B. winOpnBoost, konnte ich noch gar nicht setzen/ändern.

a) Die Devices brauchen mit unter etwas Zeit, ihre Register zu flashen. Es kommt bei einigen vor, dass darueber das Kommunikationszeitfenster austimed. Insbesondere wakeup devices sind davon betroffen (u.a. TC, VD, RT,...). Linderung bringt "perp/exec". Man bereitet also alle Aenderungen vor (prep) und sendet dann (exec). Aenderungen in einer Liste eines Device sollten dann problemlos funktionieren. Alles andere wird beim naechsten Erwachen erledigt.

b) zu sonstigen Problemen kann ich nicht pauschal Stellung nehmen. Da muesstest du rohmessages loggen und das Problem im detail beschreiben

Gruss Martim

[CQuadrat]

a) Die Devices brauchen mit unter etwas Zeit, ihre Register zu flashen. Es kommt bei einigen vor, dass darueber das Kommunikationszeitfenster austimed. Insbesondere wakeup devices sind davon betroffen (u.a. TC, VD, RT,...). Linderung bringt "perp/exec". Man bereitet also alle Aenderungen vor (prep) und sendet dann (exec). Aenderungen in einer Liste eines Device sollten dann problemlos funktionieren. Alles andere wird beim naechsten Erwachen erledigt.

Naja, bei einem simplen

Code Auswählen Erweitern

set <TC> regSet winOpnBoost on sollte ich eigentlich keine Timingprobleme bekommen.
Das Setzen von Templisten mit prep/exec vorbereiten ist mir schon klar; so mache ich das auch beim RT.

[martinp876]

ok, stimmt - dann schritt 2: logge einmal.
geht es generell oder manchmal nicht?

[CQuadrat]

ok, stimmt - dann schritt 2: logge einmal.
geht es generell oder manchmal nicht?

Okay, loggen kann ich erst heute abend -> kommt dann noch.

Ehrlich gesagt konnte ich noch kein einziges Register direkt setzen/ändern.
Das einzige (aber derzeit das wesentlichte! ) was funktioniert(e), ist peeren mit RT und SC, ändern der desired-temp und Wechsel von auto- auf manu-Mode (und umgekehrt).

[geek]

Hi,

so ganz run läufts mit dem TC bei mir auch noch nicht:
- pairen ging
- temperatur + humidity werden geliefert (humidity scheint aber deutlich weniger zu sein als bei dem hässlichen silbernen TH sensor den er ersetzt).
- peeren von _weather mit 2 RT war erfolgreich

peeren von _climate liefert ein NACK - auch per peerBulk:

Code Auswählen Erweitern

2014.02.14 16:22:30.210 2: CUL_HM set eg_wz_temp_climate peerBulk 2221D902
2014.02.14 16:22:30.210 0: HMLAN_Send:  HMEG I:+260312,00,00,
2014.02.14 16:22:30.211 0: HMLAN_Send:  HMEG S:+260312,00,01,
2014.02.14 16:22:30.211 0: HMLAN_Send:  HMEG S:S30FDE906 stat:  00 t:00000000 d:01 r:30FDE906 m:F9 B001 83D2E0 260312 02012221D90200
2014.02.14 16:22:30.725 0: HMLAN_Parse: HMEG R:R30FDE906 stat:0001 t:1FA6E2DC d:FF r:FFD8     m:F9 8002 260312 83D2E0 85
2014.02.14 16:22:30.734 0: HMLAN_Parse: HMUG R:E260312   stat:0000 t:61D1A848 d:FF r:FFA5     m:F9 8002 260312 83D2E0 85
2014.02.14 16:22:49.152 0: HMLAN_Send:  HMEG I:K
2014.02.14 16:22:49.153 0: HMLAN_Send:  HMUG I:K
2014.02.14 16:22:49.156 0: HMLAN_Parse: HMEG V:03C1 sNo:KEQ0852556 d:23A63A O:83D2E0 t:1FA72ADD IDcnt:0018
2014.02.14 16:22:49.156 0: HMLAN_Parse: HMUG V:03C1 sNo:KEQ0852689 d:23A636 O:83D2E1 t:61D1F04E IDcnt:0009
2014.02.14 16:22:53.238 0: HMLAN_Parse: HMUG R:E221F1C   stat:0000 t:61D2003B d:FF r:FFCD     m:D6 8610 221F1C 000000 0A88AA0F1058
2014.02.14 16:22:53.261 0: HMLAN_Parse: HMEG R:E221F1C   stat:0000 t:1FA73ACB d:FF r:FFAE     m:D6 8610 221F1C 000000 0A88AA0F1058
2014.02.14 16:22:58.129 0: HMLAN_Parse: HMEG R:E1F4BD5   stat:0000 t:1FA74DE7 d:FF r:FFC5     m:0C 8670 1F4BD5 000000 00AA31
2014.02.14 16:22:58.156 0: HMLAN_Parse: HMUG R:E1F4BD5   stat:0000 t:61D21357 d:FF r:FFB9     m:0C 8670 1F4BD5 000000 00AA31
2014.02.14 16:22:59.523 0: HMLAN_Parse: HMUG R:E260312   stat:0000 t:61D218C9 d:FF r:FFA2     m:62 865A 260312 000000 88C030
2014.02.14 16:22:59.536 0: HMLAN_Parse: HMEG R:E260312   stat:0000 t:1FA75359 d:FF r:FFD8     m:62 865A 260312 000000 88C030


setzen von registern scheitert mit NACK:

Code Auswählen Erweitern

2014.02.14 16:36:48.676 2: CUL_HM set eg_wz_temp_climate regSet nightTemp 19
2014.02.14 16:36:48.676 0: HMLAN_Send:  HMEG S:S310B0268 stat:  00 t:00000000 d:01 r:310B0268 m:FC B001 83D2E0 260312 02050000000007
2014.02.14 16:36:49.185 0: HMLAN_Parse: HMEG R:R310B0268 stat:0001 t:1FB3FCBA d:FF r:FFD9     m:FC 8002 260312 83D2E0 85
2014.02.14 16:36:49.198 0: HMLAN_Parse: HMUG R:E260312   stat:0000 t:61DEC22C d:FF r:FFA3     m:FC 8002 260312 83D2E0 85
2014.02.14 16:36:56.515 0: HMLAN_Parse: HMEG R:E22C44C   stat:0000 t:1FB41958 d:FF r:FFCF     m:28 8610 22C44C 000000 0A88AC100058
2014.02.14 16:36:56.536 0: HMLAN_Parse: HMUG R:E22C44C   stat:0000 t:61DEDECE d:FF r:FFB1     m:28 8610 22C44C 000000 0A88AC100058


dabei ist:
- HMID des zu peerenden RT: 2221D9
- HMID des TC: 260312
- der TC hat sauber den HMLAN mit HMEG/83D2E0 als IODev.

Code Auswählen Erweitern

# $Id: 10_CUL_HM.pm 4901 2014-02-12 19:46:49Z martinp876 $
# $Id: 00_HMLAN.pm 4872 2014-02-10 17:37:46Z martinp876 $
# $Id: 98_HMinfo.pm 4896 2014-02-12 17:53:52Z martinp876 $


Sonst bin ich fasziniert wie schnell dafür der Support aus dem Boden schießt 

Rainer

[betateilchen]

(humidity scheint aber deutlich weniger zu sein als bei dem hässlichen silbernen TH sensor den er ersetzt).

Abwarten. Bei mir hat es 3-4 Stunden gedauert, dann waren der Wandthermostat und der TH-I in ihren Werten synchron. Der Feuchtigkeitswert im TC stieg während der Zeit kontinuierlich an, das braucht eben seine Zeit.

[geek]

Hi,

Abwarten. Bei mir hat es 3-4 Stunden gedauert, dann waren der Wandthermostat und der TH-I in ihren Werten synchron. Der Feuchtigkeitswert im TC stieg während der Zeit kontinuierlich an, das braucht eben seine Zeit.

Nach ein paar Stunden eingewöhnen wars gestern ja ok - sonst hätte ich den TH noch nicht recycled. Aber heute passen die Werte nicht zur baseline.
Normal ist der Raum nie unter 50% wenn ich heimkehre - heute zeigt er 45%. Kann mir nicht vorstellen, daß der minimal andere Platz (gleiche Höhe, 20cm näher an einer "warmen" Innenwand) so viel ausmacht. Aber klar - ohne Referenz/anderm Platz ist das alles nur "ein Gefühl"

Rainer

[martinp876]

Zum Peeren:
evtl hat der TCIT kein standard verhalten?
Warum peerst du eigentlich mit peerBulk? Egal
probiere einmal peering variante "aktor"

set <TCdevice> raw ++B00183D2E026031202012221D90202

und bitte loggen

[betateilchen]

Das Thema "Register setzen" im TC ist noch ein spannendes Thema, das funktioniert meistens nicht.

Das Register tempMax lässt sich z.B. auch nicht setzen. Welche Logs/Infos brauchst Du dafür?