Hallo Zusammen,
ich habe mir oben genannten Regensensor als Bausatz zugelegt. Leider ist keine Aufbauanleitung dabei, deshalb die Frage - kann mir einer die Pinbelegung zwischen dem Sensor im Deckel und der Platine geben?
Zweite Frage, angeblich hat der Sensor eine Heizung - lässt sich diese über FHEM ansprechen, bzw. konfigurieren?
Habe leider im Wiki nichts dazu gefunden...
Vielen Dank und liebe Grüße
trilu
Hallo Trilu !
So etwas habe ich bei ELV noch nie erlebt. Am besten direkt telefonisch nachfragen.
Im aktuellen ELV Journal wurde der Sensor vorgestellt. Entsprechend sollte der
Artikel bei ELV als Download zur Verfügung stehen. Folgendes steht in dem Artikel
(diese Artikel enstprechen im Regelfall den Einbauanleitungen):
ST1 = rot
ST2 = gelb
ST3 = schwarz
Der Sensor ist in der aktuellen HMConfig.pm bereits erfasst.
"00A7" => {name=>"HM-Sen-RD-O" ,st=>'' ,cyc=>'' ,rxt=>'' ,lst=>'1:1,4:1' ,chn=>"Rain:1:1,Sw:2:2",}
Der zweite Channel (Sw) sieht für mich stark nach dem Schalter für die Heizung aus. Falls nicht,
kann wohl nur Martin helfen ...
Gruß, Marc
Vielen Dank - werde gleich mal testen!
Kabel angelötet und Regenstatus wird angezeigt - Klasse!
Blöd ist aber, und hier komme ich nicht weiter, die Heizung ist per Default an und das Ding wird ganz schön warm :-)
Leider habe ich keine Ahnung wie man die Heizung, oder generell, die Parameter konfiguriert.
Anbei ein Log:
2013-07-27_19:58:12 CUL_HM_HM_Sen_RD_O_20EC71 noReceiver: src:20EC71 A610 0602C800
2013-07-27_19:58:15 CUL_HM_HM_Sen_RD_O_20EC71 noReceiver: src:20EC71 A610 06010000
2013-07-27_19:58:41 CUL_HM_HM_Sen_RD_O_20EC71 CMDs_pending
2013-07-27_19:58:41 CUL_HM_HM_Sen_RD_O_20EC71 CMDs_processing...
2013-07-27_19:58:41 CUL_HM_HM_Sen_RD_O_20EC71 CommandAccepted: no
2013-07-27_19:58:41 CUL_HM_HM_Sen_RD_O_20EC71 CMDs_done_events:1
2013-07-27_19:58:41 CUL_HM_HM_Sen_RD_O_20EC71 NACK
2013-07-27_20:00:14 CUL_HM_HM_Sen_RD_O_20EC71 CMDs_pending
2013-07-27_20:00:14 CUL_HM_HM_Sen_RD_O_20EC71 CMDs_processing...
2013-07-27_20:00:14 CUL_HM_HM_Sen_RD_O_20EC71 CommandAccepted: no
2013-07-27_20:00:14 CUL_HM_HM_Sen_RD_O_20EC71 CMDs_done_events:2
2013-07-27_20:00:14 CUL_HM_HM_Sen_RD_O_20EC71 NACK
2013-07-28_10:45:42 CUL_HM_HM_Sen_RD_O_20EC71 noReceiver: src:20EC71 A610 0602C800
Interessieren würden mich auch die Meldungen "CommandAccepted: no" und ganz besonders "noReceiver: src:20EC71 A610 0602C800"
Vielleicht kann mir ja hier jemand helfen. Bin auch im Gegenzug bereit den Wiki Eintrag zu füllen...
Viele Grüße
trilu
Hallo Trilu,
ich habe einmal etwas probiert, werde es gleich einchecken. Also entweder 10_CULHM und HMCONFIGaus SVN laden oderbis morgen warten und normalen Update machen.
Der RD hat 2 channels- defaults habe ich umbenannt. Du könntest also die beiden Channels löschen (nicht das Device) und kurz anlernen drücken. Dann hast du die neuen.
Channel 2 ist für die Heizung. Da sollten jetzt die set-kommandos gehen. Aktuell geht nur an/aus. Sollte da auch ein Level funktionieren?
Channel 1 zeigt "rain" oder "dry". Du kannst über Register des Channel 1ein paar Filter setzen - musst du aber selbst probieren. Irgendwie sollte dies die Empfindlichkeit steuern.
Du könntest dann ein getConfig machen, expert auf 2 setzen und dann ein List aller Entities schicken.
Channel 1 sollte man peeren können, dann sollten da ggf trigger kommen mit denen man andere Devices steuern kann. Hier könntest du einmal die messages roh aufzeichnen.
Gruss Martin
Hi !
Gemäß des Artikels im ELV Journal, kann man die Heizung wohl nur ein- und ausschalten
(und das auch nur dann wenn man eine Zentrale - oder FHEM :-) - hat, sonst ist sie
immer an). Level kann man wohl nicht einstellen. Nach einem Ausfall der Versorgungs-
spannung wird die Heizung wohl grundsätzlich auch wieder aktiviert. Es wäre also wohl
sinnvoll, den "Power On" Event des Sensors abzufangen, um die Heizung erst einmal
sofort wieder abzuschalten. Komische Defaulteinstellung ...
Gruß, Marc
Hallo Martin,
vielen Dank das du dich des Regensensors annimmst.
Ich bin mir nicht ganz sicher ob ich dich richtig verstanden habe :-)
Ich habe heute früh ein Update gemacht - gestern Abend ging nicht, da zu heiß im Büro.
Nach dem Update die zwei Channels raus gelöscht und expert auf 2 gesetzt per
attr CUL_HM_HM_Sen_RD_O_20EC71 expert 2_full
Ist das richtig so?
Wenn ich jetzt getConfig in der Web Oberfläche klicke bekomme ich zurück:
PairedTo 0x631963 2013-07-29 09:28:20
R-intKeyVisib invisib 2013-07-29 09:28:20
R-pairCentral 0x631963 2013-07-29 09:28:20
RegL_00: 02:01 0A:63 0B:19 0C:63 14:06 18:00 00:00 2013-07-29 09:28:20
RegL_01: 08:00 22:64 23:05 30:06 00:00 2013-07-29 09:28:21
RegL_04: 01:00 00:00 2013-07-29 09:28:21
noReceiver src:20EC71 8002 010200003F 2013-07-29 09:18:43
Den Pair Button kann ich erst heute Abend drücken, bin gerade nicht in der nähe des Regensensors.
Update folgt!
Ich bin mir nicht sicher ob ich das mit dem Peeren richtig verstehe - Peeren geht nur mit anderen HM Devices oder?
Mein Problem ist - ich habe derzeit nur zwei von diesen 6Fach Tastern, den HM USB Stick und diesen Sensor....
Falls ich irgendwie anders an die Notify Meldung komme, dann bitte um kurze Anleitung.
Viele Grüße
trilu
Hi Trilu
ZitatNach dem Update die zwei Channels raus gelöscht
danach kurz Anlernen, FHEM sollte die Channels neu anlegen (wenn sie schon existieren passiert dies nicht).
Somit solltest du auf einem aktuellen Stand der Channels sein.
das "no receiver" sollte dann nicht mehr kommen.
Nachdem du die neuen Channels hast solltest du einmal ein
set CUL_HM_HM_Sen_RD_O_20EC71 getConfig machen.
FHEM sollte jetzt die Register auslesen und darstellen.
pairen/peeren
pairen kann man Devices mit einer Zentrale. Das sollte man mit jeden Device auch tun.
peeren kann man channels mit anderen Channels. Also einen Sensor/taster mit einem Aktor. Meist kann ein Channel mehrere peers haben. Also ein Button mehrere Aktoren sowie ein Aktor mehrere Buttons.
Channel 1 ist ein Sensor und kann als solcher gepeert werden. Du könntest damit einen Aktor steuern und das Licht einschalten wenn es regnet :-)
Zum testen schlage ich einen virtuellen Aktor vor:
define va CUL_HM 123456
set va virtual 1
jetzt hast du einen Aktor-channel (virtuell) va_Btn1. Egal, dass er Btn heist.. wirnehmen ihn als Aktor.
Den kannst du jetzt peeren
set <rd_chn1> peerChan 0 va_Btn1 single set
ein "save" speichert die Einstellungen des va, der RD speichert es generell
dann noch einmal ein getConfig, nun sollten die Peers in der Liste erscheinen.
Der RD sollte nun events erzeugen - keine Ahnung wann. Ich denke einmal wenn es regnet. Dann sollte er den va_Btn1 informieren. Spielzeit.
Gruss Martin
wow, danke für die Anleitung
Ich habe jetzt das Device eingebunden als
CUL_HM_HM_Sen_RD_O_20EC71
Zusätzlich folgende zwei Kanäle
CUL_HM_HM_Sen_RD_O_20EC71_Heating ??? on off
CUL_HM_HM_Sen_RD_O_20EC71_Rain dry
Beim Heating Kanal kann ich über on und off die Heizung schalten...
Das Device zeigt jetzt bei getConfig folgendes an:
CommandAccepted yes 2013-07-29 20:03:07
PairedTo 0x631963 2013-07-29 19:59:59
R-intKeyVisib invisib 2013-07-29 13:36:18
R-localResDis off 2013-07-29 19:59:35
R-pairCentral 0x631963 2013-07-29 13:36:18
R-transmDevTryMax 6 2013-07-29 19:59:35
RegL_00: 02:01 0A:63 0B:19 0C:63 14:06 18:00 00:00 2013-07-29 19:59:59
RegL_01: 08:00 22:64 23:05 30:06 00:00 2013-07-29 13:36:19
RegL_04: 01:00 00:00 2013-07-29 13:36:20
state CMDs_done 2013-07-29 20:03:13
getConfig bei CUL_HM_HM_Sen_RD_O_20EC71_Rain
RegL_01:
state dry 2013-07-29 20:03:13
trigger 2 2013-07-29 20:03:12
getConfig bei CUL_HM_HM_Sen_RD_O_20EC71_Heating bringt keine Rückmeldung
Das Log zum virtuellen Button sieht so aus:
2013-07-29_20:03:12 va_Btn1 ON
2013-07-29_20:03:12 va_Btn1 virtActState: ON
2013-07-29_20:03:12 va_Btn1 virtActTrigger: CUL_HM_HM_Sen_RD_O_20EC71_Rain
2013-07-29_20:03:12 va_Btn1 virtActTrigType: short_Release
2013-07-29_20:03:12 va_Btn1 virtActTrigRpt: 1
2013-07-29_20:03:12 va_Btn1 virtActTrigNo: 2
2013-07-29_20:11:56 va_Btn1 OFF
2013-07-29_20:11:56 va_Btn1 virtActState: OFF
2013-07-29_20:11:56 va_Btn1 virtActTrigger: CUL_HM_HM_Sen_RD_O_20EC71_Rain
2013-07-29_20:11:56 va_Btn1 virtActTrigType: short_Release
2013-07-29_20:11:56 va_Btn1 virtActTrigRpt: 1
2013-07-29_20:11:56 va_Btn1 virtActTrigNo: 3
Das ist der Rain Channel:
2013-07-29_20:03:12 CUL_HM_HM_Sen_RD_O_20EC71_Rain R-expectAES: off
2013-07-29_20:03:12 CUL_HM_HM_Sen_RD_O_20EC71_Rain R-peerNeedsBurst: off
2013-07-29_20:03:12 CUL_HM_HM_Sen_RD_O_20EC71_Rain trigger: 2
2013-07-29_20:03:13 CUL_HM_HM_Sen_RD_O_20EC71_Rain dry
2013-07-29_20:11:56 CUL_HM_HM_Sen_RD_O_20EC71_Rain R-expectAES: off
2013-07-29_20:11:56 CUL_HM_HM_Sen_RD_O_20EC71_Rain R-peerNeedsBurst: off
2013-07-29_20:11:56 CUL_HM_HM_Sen_RD_O_20EC71_Rain trigger: 3
2013-07-29_20:11:56 CUL_HM_HM_Sen_RD_O_20EC71_Rain rain
2013-07-29_20:12:10 CUL_HM_HM_Sen_RD_O_20EC71_Rain trigger: 4
2013-07-29_20:12:11 CUL_HM_HM_Sen_RD_O_20EC71_Rain dry
Im Log des Devices hat sich nichts getan...
Die peerID sehe ich nur in den Attributen des va_Btn1 Devices.
Im CUL_HM_HM_Sen_RD_O_20EC71 Devices steht folgendes unter Attributes
expert 2_full deleteattr
firmware 1.3 deleteattr
model HM-Sen-RD-O deleteattr
peerIDs deleteattr
room CUL_HM deleteattr
serialNr KEQ0117104 deleteattr
subType sensRain deleteattr
webCmd getConfig deleteattr
Scheint aber zu funktionieren :-)
Vielen Dank!!!!!!!
Falls du weitere Info's brauchst, jederzeit gerne....
trilu
Rein interessehalber:
Eigentlich muss doch da auch noch eine interne Verknüpfung zwischen dem Sensor und der Heizung vorhanden sein, denn der Sensor schaltet die Heizung doch bei Regen automatisch ein.
Hast Du schonmal probiert, ob man nach einem
set <device> regSet intKeyVisib visib
mit anschließendem getConfig noch mehr Informationen bekommt?
Mhh, kommt auch nicht mehr...
CommandAccepted
yes
2013-07-29 21:22:27
PairedTo
0x631963
2013-07-29 21:20:11
R-intKeyVisib
visib
2013-07-29 21:20:11
R-localResDis
off
2013-07-29 19:59:35
R-pairCentral
0x631963
2013-07-29 13:36:18
R-transmDevTryMax
6
2013-07-29 19:59:35
RegL_00:
RegL_01:
08:00 22:64 23:05 30:06 00:00
2013-07-29 13:36:19
RegL_04:
01:00 00:00
2013-07-29 13:36:20
state
CMDs_pending
2013-07-29 21:22:35
Was bedeuten eigentlich die Nummern bei den RegL Zeilen?
Dein Listing ist noch nicht komplett. Da sind noch "cmds pending" Drück nochmal kurz (!) die Konfigurationstaste.
Die RegL_xx sind Registernummern im Speicher des Gerätes.
Ok, diesmal ohne cmd pending :-)
Readings
CommandAccepted
yes
2013-07-29 21:22:27
PairedTo
0x631963
2013-07-29 21:31:32
R-intKeyVisib
visib
2013-07-29 21:20:11
R-localResDis
off
2013-07-29 19:59:35
R-pairCentral
0x631963
2013-07-29 13:36:18
R-transmDevTryMax
6
2013-07-29 19:59:35
RegL_00:
02:81 0A:63 0B:19 0C:63 14:06 18:00 00:00
2013-07-29 21:31:32
RegL_01:
08:00 22:64 23:05 30:06 00:00
2013-07-29 13:36:19
RegL_04:
01:00 00:00
2013-07-29 13:36:20
state
CMDs_done
2013-07-29 21:31:33
merkwürdig...
Ich seh schon, ich muss mir auch mal so einen Sensor zum Spielen besorgen *g*
Sag in der Zwischenzeit einfach was ich probieren soll. Mach ich gerne, kann ja dabei nur lernen :-)
Ich kann dir auch mal einen Port öffnen so das du selbst testen kannst...
Hi trilu,
ob die Heizung auch automatisch angehen kann weiss ich nicht.
Aber es fehlt in jeden Fall noch die Register List1 des rain channel.
kannst
attr global verbose 1
attr <hmlan> loglevel 1
dann ein
set CUL_HM_HM_Sen_RD_O_20EC71 getConfig
und das Ergebnis aus den generellen logfile schicken
ausserdem - hast du den rainchannel schon gepeert - zum testen? kann ich nicht sehen, dass etwas in der Liste steht, aber da eine List4 besteht sollte es so sein.
Wenn du mit den Logeinstellungen es dann noch einmal regnen lässt - dann können wir versuchen die erwarteten trigger zu finden
Gruss Martin
Zitat von: martinp876 schrieb am Di, 30 Juli 2013 08:30ob die Heizung auch automatisch angehen kann weiss ich nicht.
Hallo Martin,
ohne diese autarke Möglichkeit des Schaltens der Heizung wäre der Sensor eigentlich ziemlich sinnlos ;)
Viele Grüße
Udo
aus der Anleitung:
ZitatDie Heizung des Regensensors ist über einen Zentralenbefehl u.a. in Programmen steuerbar. Jedoch ist die Heizung aus Gründen der Betriebssicherheit nach einer Spannungswiederkehr nach Spannungsausfall immer eingeschaltet.
Bei einer direkten Aktorvernüpfung ist die Sensorheizung dauerhaft eingeschaltet
da kann ich nicht erkennen, dass der es automatisch geht
- default Heizung dauer-ein nach Spannungsausfall.
- direkte verknüpfung: dauer-ein (nicht 100% klar - kann die Zentrale dann nicht mehr ausschalten?)
- von der Zentrale aus steuerbar.
Was ich machen würde, in FHEM mittels notify:
- heizung aus nach powerOn
- heizung ein nach ende regen für x minuten.
Frage an trilu: wird power-on korrekt gemeldet?
Die beiden Funktionen könnte man in CUL_HM einbauen um unnötigen Notify-aufwand zu vermeiden. Braucht ihr so etwas? Konnte ich mir in einem attribut so vorstellen
attr rd_heating devParam powerOn:off,heatAfterRain:10
Das wäre ein attribut mit einer device-spezifischen parameterliste (oder channel-spezifisch)
Gruss Martin
trilu
noch etwas
kannst du einmal
attr global showInternalValues 1
setzen und dann ein list des RD devices machen? mich interessiert der Wert von '.stc'
danach kannst du
attr global showInternalValues 0
setzen, ist schöner
Danke
Martin
Zitat von: martinp876 schrieb am Di, 30 Juli 2013 10:00Was ich machen würde, in FHEM mittels notify:
- heizung ein nach ende regen für x minuten.
Wozu? Wenn der Sensor nach dem Abtrocknen der Meßfläche OHNE HEIZUNG bereits erkannt hat, dass es nicht mehr regnet, braucht man auch die Heizung nicht mehr einschalten, denn dann ist er schon trocken. Der Sinn der Heizung ist doch, die Sensorfläche möglichst trocken (im Winter: schneefrei) zu halten, um den andauernden Regen überhaupt erkennen zu können.
Hi,
ZitatDer Sinn der Heizung ist doch, die...
ok - habe den Sensor nicht angesehen. Man kann die Heizung auch bei beginn des Regens einschalten - falls dass sinn macht.
Da ich keine Ahnung habe, wie der Regen erkannt wird, ob nieseln auch schon einen Trigger liefert,...
Wann macht dann ein Einschalten Sinn? Immer bei "rain" und aus bei "dry"? oder besser garnicht?
Falls etwas gebaut wird wird es der User in jeden Fall abschalten können.
Gruss Martin
Zitat von: martinp876 schrieb am Di, 30 Juli 2013 13:53Wann macht dann ein Einschalten Sinn? Immer bei "rain" und aus bei "dry"?
Genau das ist der Gedanke dahinter. Die Sensorfläche trocken (im Winter schneefrei) zu halten, um einen Niederschlag auch wirklich erkennen zu können. Im Prinzip: "An" bei "Niederschlag erkannt" und "Aus" bei "kein Niederschlag"
Ich habe auch grade so einen Sensor auf den Tisch bekommen, da ich aber heute abend nicht nach Hause komme, kann ich wahrscheinlich erst morgen abend damit spielen.
nun, ich denke dann ist es sinnvoll einen "automode" bereitzustellen. Da dies über attribute passieren muss denke ich mein Vorschlag ist nicht so schlecht, ein Attribut in dem man entsprechende funktionen der Aktoren oder channels festlegt.
Ein notify ist möglich aber kostet deutlich mehr Performance.
attr rd_heat param offAtPowerOn,onAtRain
param ist Kanal-spezifisch und wird im Commandref beschrieben
param lassen sich einzeln setzen
hier würde bei
offAtPowerOn: bei powerOn wird die Heizung ausgeschaltet
onAtRain: bei trigger Rain geht die Heizung an, bei dry geht sie aus.
der User kann auch schalten - beim nächsten Ereigniss schaltet die Automatic
Prinzip von param wäre m.E.
- definition von Verhalten innerhalb eines Devices und seiner channels
geregelt würden NICHT
- Dinge die über Register funktionieren
- Beziehungen und Verhalten über mehrere Devices
macht sinn oder zu komplex?
Hallo Zusammen,
ich habe jetzt mal das Device aus der fhem.conf geschmissen und noch mal komplett neu angelernt. Jetzt sieht das getConf etwas anders aus. Das bekomme ich beim Device nach getConf zurück
Readings
CommandAccepted
yes
2013-07-30 16:02:10
PairedTo
0x631963
2013-07-30 16:31:07
R-intKeyVisib
visib
2013-07-30 16:31:07
R-localResDis
off
2013-07-30 15:53:12
R-pairCentral
0x631963
2013-07-30 15:53:12
R-transmDevTryMax
6
2013-07-30 15:53:12
RegL_00:
02:81 0A:63 0B:19 0C:63 14:06 18:00 00:00
2013-07-30 16:31:07
state
CMDs_done_events:2
2013-07-30 16:31:08
Hier ist ein Log von getConf
2013.07.30 16:31:07 1: HMLAN_Send: HMUSB S:S2FFD5A0D stat: 00 t:00000000 d:01 r:2FFD5A0D m:18 A001 631963 20EC71 00040000000000
2013.07.30 16:31:07 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1931A44F d:FF r:FFB9 m:18 A010 20EC71 631963 0202810A630B190C63140618000000
2013.07.30 16:31:07 1: HMLAN_Delay: HMUSB 20EC71
2013.07.30 16:31:07 1: HMLAN_Parse: HMUSB R:R2FFD5A0D stat:0001 t:1931A454 d:FF r:FFB9 m:18 A010 20EC71 631963 0202810A630B190C63140618000000
2013.07.30 16:31:07 1: HMLAN_SdDly: HMUSB 20EC71
2013.07.30 16:31:07 1: HMLAN_Send: HMUSB S:+20EC71,00,01,
2013.07.30 16:31:07 1: HMLAN_Send: HMUSB S:S2FFD5B4B stat: 00 t:00000000 d:01 r:2FFD5B4B m:19 A001 631963 20EC71 01040000000001
2013.07.30 16:31:07 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1931A657 d:FF r:FFB9 m:19 A010 20EC71 631963 0208002264230530060000
2013.07.30 16:31:07 1: HMLAN_Delay: HMUSB 20EC71
2013.07.30 16:31:08 1: HMLAN_Parse: HMUSB R:R2FFD5B4B stat:0001 t:1931A65C d:FF r:FFB9 m:19 A010 20EC71 631963 0208002264230530060000
2013.07.30 16:31:08 1: HMLAN_SdDly: HMUSB 20EC71
2013.07.30 16:31:08 1: HMLAN_Send: HMUSB S:S2FFD5CFC stat: 00 t:00000000 d:01 r:2FFD5CFC m:1A A001 631963 20EC71 01040000000004
2013.07.30 16:31:08 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1931A85E d:FF r:FFB8 m:1A A010 20EC71 631963 0201000000
2013.07.30 16:31:08 1: HMLAN_Parse: HMUSB R:R2FFD5CFC stat:0001 t:1931A863 d:FF r:FFB8 m:1A A010 20EC71 631963 0201000000
2013.07.30 16:31:14 1: HMLAN_Send: HMUSB I:K
2013.07.30 16:31:14 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1931BF13 IDcnt:0001
Heizung lässt sich manuell schalten, allerdings passt das Symbol nicht - bei off bekomme ich eine gelbe Lampe, bei on eine grüne Lampe.
Wenn ich einen Regen auslöse bekomm ich das hier im Log
2013.07.30 16:36:54 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1936EF7A d:FF r:FFBA m:10 A441 20EC71 123456 0108C8
2013.07.30 16:36:54 1: HMLAN_Send: HMUSB S:+20EC71,00,01,
2013.07.30 16:36:54 1: HMLAN_Send: HMUSB S:S3002A60F stat: 00 t:00000000 d:01 r:3002A60F m:10 8002 123456 20EC71 0101C800
2013.07.30 16:36:54 1: HMLAN_Parse: HMUSB R:R3002A60F stat:0002 t:00000000 d:FF r:7FFF m:10 8002 123456 20EC71 0101C800
2013.07.30 16:36:54 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1936F08B d:FF r:FFBA m:10 A041 20EC71 123456 0108C8
2013.07.30 16:36:55 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1936F297 d:FF r:FFBA m:10 A041 20EC71 123456 0108C8
2013.07.30 16:36:56 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1936F69C d:FF r:FFBA m:10 A041 20EC71 123456 0108C8
2013.07.30 16:36:58 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1936FE91 d:FF r:FFB9 m:10 A041 20EC71 123456 0108C8
2013.07.30 16:37:02 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:19370E67 d:FF r:FFB9 m:10 A041 20EC71 123456 0108C8
2013.07.30 16:37:02 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:19370F4C d:FF r:FFB9 m:11 A610 20EC71 631963 0601C800
2013.07.30 16:37:04 1: HMLAN_Send: HMUSB I:K
2013.07.30 16:37:04 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:193717CC IDcnt:0001
Ein list des Device liefert das
list CUL_HM_HM_Sen_RD_O_20EC71
Internals:
DEF 20EC71
IODev HMUSB
NAME CUL_HM_HM_Sen_RD_O_20EC71
NR 296
STATE CMDs_done_events:2
TYPE CUL_HM
channel_01 CUL_HM_HM_Sen_RD_O_20EC71_Rain
channel_02 CUL_HM_HM_Sen_RD_O_20EC71_Heating
Readings:
2013-07-30 16:02:10 CommandAccepted yes
2013-07-30 16:31:07 PairedTo 0x631963
2013-07-30 16:31:07 R-intKeyVisib visib
2013-07-30 15:53:12 R-localResDis off
2013-07-30 15:53:12 R-pairCentral 0x631963
2013-07-30 15:53:12 R-transmDevTryMax 6
2013-07-30 16:31:07 RegL_00: 02:81 0A:63 0B:19 0C:63 14:06 18:00 00:00
2013-07-30 16:39:42 state CMDs_done_events:2
Helper:
mId 00A7
rxType 1
Role:
dev 1
Attributes:
.devInfo 040101
.stc 70
expert 2_full
firmware 1.3
model HM-Sen-RD-O
peerIDs
room CUL_HM
serialNr KEQ0117104
subType sensRain
webCmd getConfig
fhem>
Ach ja, das Thema Empfindlichkeit - leicht feuchter Finger für 5 Sekunden reicht, soll heissen, das Ding schaltet auch bei Nieselregen...
Viele Grüße
trilu
Was bringt eigentlich ein list auf die beiden Channels zutage?
@martin natürlich hast Du immer die besten Ideen :)
Aber was ich hier im Thread gerade mitlese, hört sich für mich alles irgendwie komisch an und bringt mein in den letzten Wochen gewonnenes positives Homematic-Weltbild ziemlich durcheinander. Mein Bauchgefühl (und Bauch hab ich viel...) sagt mir, dass das alles viel zu kompliziert klingt. Ich bin sehr gespannt, was ich erlebe, wenn ich mich mit meinem Sensor beschäftigen kann.
fhem> attr global showInternalValues 1
fhem> list CUL_HM_HM_Sen_RD_O_20EC71_Heating
Internals:
DEF 20EC7102
NAME CUL_HM_HM_Sen_RD_O_20EC71_Heating
NR 311
STATE on
TYPE CUL_HM
chanNo 02
device CUL_HM_HM_Sen_RD_O_20EC71
Readings:
2013-07-30 16:35:40 CommandAccepted yes
2013-07-30 16:35:40 state on
Helper:
Role:
chn 1
Attributes:
expert 1
model HM-Sen-RD-O
peerIDs
room CUL_HM
fhem>
Wobei hier der Status nicht stimmt - eigentlich ist die Heizung aus.
Hatte fhem neu gestartet...
fhem> list CUL_HM_HM_Sen_RD_O_20EC71_Rain
Internals:
DEF 20EC7101
NAME CUL_HM_HM_Sen_RD_O_20EC71_Rain
NR 305
STATE dry
TYPE CUL_HM
chanNo 01
device CUL_HM_HM_Sen_RD_O_20EC71
Readings:
2013-07-30 16:31:07 .RegL_01: 08:00 22:64 23:05 30:06 00:00
2013-07-30 16:31:08 .RegL_04: 01:00 00:00
2013-07-30 16:31:07 R-eventFilterTime 0.5 s
2013-07-30 16:31:08 R-expectAES off
2013-07-30 16:31:08 R-peerNeedsBurst off
2013-07-30 16:31:07 R-transmitTryMax 6
2013-07-30 16:39:42 state dry
2013-07-30 16:39:41 trigger 11
Helper:
Role:
chn 1
Attributes:
expert 1
model HM-Sen-RD-O
peerIDs
room CUL_HM
fhem>
Warum jetzt die peerID leer ist weiss ich nicht, die Verknüpfung zum virtuellen Button läuft noch.
Viele Grüße
trilu
Zitat von: trilu schrieb am Sa, 27 Juli 2013 20:26ich habe mir oben genannten Regensensor als Bausatz zugelegt. Leider ist keine Aufbauanleitung dabei
Falls Du die Aufbauanleitung noch haben möchtest, schick mir eine email hier über das Forum, dann scanne ich Dir die acht Seiten ein. Bei meinem Bausatz war die Anleitung dabei.
Vielen Dank für das Angebot.
In der Zwischenzeit habe ich sie von ELV bekommen. Wobei ich sie gar nicht mehr gebraucht habe, der Aufbau ist ja selbsterklärend, bis auf die Pinbelegung für die Heizung und Messchleife :-)
Hi Udo,
sicher sollten wir erstversuchen, es IM Device zu lösen.
@trilu: du hast ein list der beiden Kanäle geliefert - kannst du noch das Device nachleifern?
Warum jetzt die peerID leer ist weiss ich nicht, die Verknüpfung zum virtuellen Button läuft noch.
wenn es nach getConfig nicht vorhanden ist, kannst du bitte noch einmal das GetConfig im rohformat aufzeichnen? Sollte so nicht sein - hoffentlich kein Bug.
Und dann noch einmal die events aufzeichnen, auch roh. Wenn ein peer eingerichtet ist sollte auch trigger kommen, wenn du regen simulierst.
Gruss Martin
Klar kann ich :-)
fhem> list CUL_HM_HM_Sen_RD_O_20EC71
Internals:
.triggerUsed 1
CHANGED
DEF 20EC71
EVENTS 13
HMUSB_MSGCNT 25
HMUSB_RAWMSG R35D4C00C,0001,1F09069A,FF,FFAB,0DA01020EC716319630201000000
HMUSB_RSSI -85
HMUSB_TIME 2013-07-31 19:44:30
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 25
NAME CUL_HM_HM_Sen_RD_O_20EC71
NR 311
STATE CMDs_done_events:1
TYPE CUL_HM
channel_01 CUL_HM_HM_Sen_RD_O_20EC71_Rain
channel_02 CUL_HM_HM_Sen_RD_O_20EC71_Heating
lastMsg No:0D - t:10 s:20EC71 d:631963 0201000000
protLastRcv 2013-07-31 19:44:30
protResnd 1 last_at:2013-07-31 19:43:45
protSnd 13 last_at:2013-07-31 19:44:29
protState CMDs_done_events:1
rssi_at_HMUSB avg:-81.72 min:-86 max:-74 lst:-85 cnt:25
Readings:
2013-07-31 19:43:46 CommandAccepted yes
2013-07-31 19:44:29 PairedTo 0x631963
2013-07-31 18:03:38 R-intKeyVisib visib
2013-07-31 18:03:38 R-localResDis off
2013-07-31 18:03:38 R-pairCentral 0x631963
2013-07-31 18:03:38 R-transmDevTryMax 6
2013-07-31 19:44:29 RegL_00: 02:81 0A:63 0B:19 0C:63 14:06 18:00 00:00
2013-07-31 19:44:30 state CMDs_done_events:1
Helper:
burstEvtCnt 1
mId 00A7
rxType 1
Respwait:
Role:
dev 1
Rssi:
At_hmusb:
avg -81.72
cnt 25
lst -85
max -74
min -86
Shadowreg:
Attributes:
.devInfo 040101
.stc 70
expert 2_full
firmware 1.3
model HM-Sen-RD-O
peerIDs
room CUL_HM
serialNr KEQ0117104
subType sensRain
webCmd getConfig
fhem>
Hab noch mal neu gepeert, aber PeerId bleibt leer.
Getconfig im Rohformat:
2013.07.31 19:49:33 1: HMLAN_Send: HMUSB I:K
2013.07.31 19:49:33 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1F0DA6B5 IDcnt:0001
2013.07.31 19:49:58 1: HMLAN_Send: HMUSB I:K
2013.07.31 19:49:58 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1F0E087B IDcnt:0001
2013.07.31 19:50:23 1: HMLAN_Send: HMUSB I:K
2013.07.31 19:50:23 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1F0E6A42 IDcnt:0001
2013.07.31 19:50:48 1: HMLAN_Send: HMUSB I:K
2013.07.31 19:50:48 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1F0ECBE9 IDcnt:0001
2013.07.31 19:51:06 1: HMLAN_Send: HMUSB S:+20EC71,00,01,
2013.07.31 19:51:06 1: HMLAN_Send: HMUSB S:S35DACF10 stat: 00 t:00000000 d:01 r:35DACF10 m:11 A001 631963 20EC71 00040000000000
2013.07.31 19:51:07 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1F0F14CA d:FF r:FFB5 m:11 A010 20EC71 631963 0202810A630B190C63140618000000
2013.07.31 19:51:07 1: HMLAN_Delay: HMUSB 20EC71
2013.07.31 19:51:07 1: HMLAN_Parse: HMUSB R:R35DACF10 stat:0001 t:1F0F14CF d:FF r:FFB5 m:11 A010 20EC71 631963 0202810A630B190C63140618000000
2013.07.31 19:51:07 1: HMLAN_SdDly: HMUSB 20EC71
2013.07.31 19:51:07 1: HMLAN_Send: HMUSB S:+20EC71,00,01,
2013.07.31 19:51:07 1: HMLAN_Send: HMUSB S:S35DAD33C stat: 00 t:00000000 d:01 r:35DAD33C m:12 A001 631963 20EC71 01040000000001
2013.07.31 19:51:08 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1F0F1907 d:FF r:FFB5 m:12 A010 20EC71 631963 0208002264230530060000
2013.07.31 19:51:08 1: HMLAN_Delay: HMUSB 20EC71
2013.07.31 19:51:08 1: HMLAN_Parse: HMUSB R:R35DAD33C stat:0001 t:1F0F190C d:FF r:FFB5 m:12 A010 20EC71 631963 0208002264230530060000
2013.07.31 19:51:08 1: HMLAN_SdDly: HMUSB 20EC71
2013.07.31 19:51:08 1: HMLAN_Send: HMUSB S:S35DAD761 stat: 00 t:00000000 d:01 r:35DAD761 m:13 A001 631963 20EC71 01040000000004
2013.07.31 19:51:09 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1F0F1CE3 d:FF r:FFB5 m:13 A010 20EC71 631963 0201000000
2013.07.31 19:51:09 1: HMLAN_Parse: HMUSB R:R35DAD761 stat:0001 t:1F0F1CE8 d:FF r:FFB5 m:13 A010 20EC71 631963 0201000000
Das sollte ein Rain event sein:
2013.07.31 19:51:16 1: HMLAN_Send: HMUSB I:K
2013.07.31 19:51:16 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1F0F39B0 IDcnt:0001
2013.07.31 19:51:41 1: HMLAN_Send: HMUSB I:K
2013.07.31 19:51:41 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1F0F9B75 IDcnt:0001
2013.07.31 19:52:06 1: HMLAN_Send: HMUSB I:K
2013.07.31 19:52:06 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1F0FFD3B IDcnt:0001
2013.07.31 19:52:31 1: HMLAN_Send: HMUSB I:K
2013.07.31 19:52:31 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1F105EE1 IDcnt:0001
2013.07.31 19:52:56 1: HMLAN_Send: HMUSB I:K
2013.07.31 19:52:56 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1F10C0A8 IDcnt:0001
2013.07.31 19:53:21 1: HMLAN_Send: HMUSB I:K
2013.07.31 19:53:21 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1F11224E IDcnt:0001
2013.07.31 19:53:43 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1F1178AF d:FF r:FFB8 m:1F A441 20EC71 123456 010FC8
2013.07.31 19:53:43 1: HMLAN_Send: HMUSB S:S35DD3446 stat: 00 t:00000000 d:01 r:35DD3446 m:1F 8002 123456 20EC71 01010000
2013.07.31 19:53:44 1: HMLAN_Parse: HMUSB R:R35DD3446 stat:0002 t:00000000 d:FF r:7FFF m:1F 8002 123456 20EC71 01010000
2013.07.31 19:53:44 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1F117981 d:FF r:FFB8 m:20 A610 20EC71 631963 0601C800
2013.07.31 19:53:46 1: HMLAN_Send: HMUSB I:K
2013.07.31 19:53:46 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1F118415 IDcnt:0001
2013.07.31 19:54:11 1: HMLAN_Send: HMUSB I:K
2013.07.31 19:54:11 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:1F11E5BC IDcnt:0001
2013.07.31 19:54:21 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1F120E41 d:FF r:FFB7 m:21 A441 20EC71 123456 011000
2013.07.31 19:54:22 1: HMLAN_Send: HMUSB S:S35DDC9C6 stat: 00 t:00000000 d:01 r:35DDC9C6 m:21 8002 123456 20EC71 0101C800
2013.07.31 19:54:22 1: HMLAN_Parse: HMUSB R:R35DDC9C6 stat:0002 t:00000000 d:FF r:7FFF m:21 8002 123456 20EC71 0101C800
2013.07.31 19:54:22 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:1F120F0B d:FF r:FFB6 m:22 A610 20EC71 631963 06010000
Das ist das log des virtuellen Buttons - also Trigger funktioniert:
2013-07-31_19:53:43 va_Btn1 OFF
2013-07-31_19:53:43 va_Btn1 virtActState: OFF
2013-07-31_19:53:43 va_Btn1 virtActTrigger: CUL_HM_HM_Sen_RD_O_20EC71_Rain
2013-07-31_19:53:43 va_Btn1 virtActTrigType: short_Release
2013-07-31_19:53:43 va_Btn1 virtActTrigRpt: 1
2013-07-31_19:53:43 va_Btn1 virtActTrigNo: 15
2013-07-31_19:54:22 va_Btn1 ON
2013-07-31_19:54:22 va_Btn1 virtActState: ON
2013-07-31_19:54:22 va_Btn1 virtActTrigger: CUL_HM_HM_Sen_RD_O_20EC71_Rain
2013-07-31_19:54:22 va_Btn1 virtActTrigType: short_Release
2013-07-31_19:54:22 va_Btn1 virtActTrigRpt: 1
2013-07-31_19:54:22 va_Btn1 virtActTrigNo: 16
Das ist das log des Rain devices:
2013-07-31_19:53:43 CUL_HM_HM_Sen_RD_O_20EC71_Rain R-expectAES: off
2013-07-31_19:53:43 CUL_HM_HM_Sen_RD_O_20EC71_Rain R-peerNeedsBurst: off
2013-07-31_19:53:43 CUL_HM_HM_Sen_RD_O_20EC71_Rain trigger: 15
2013-07-31_19:53:44 CUL_HM_HM_Sen_RD_O_20EC71_Rain rain
2013-07-31_19:54:22 CUL_HM_HM_Sen_RD_O_20EC71_Rain trigger: 16
2013-07-31_19:54:22 CUL_HM_HM_Sen_RD_O_20EC71_Rain dry
Warum die PeerId nicht angezeigt wird ist mir ein Rätsel. So setze ich die peerId:
set CUL_HM_HM_Sen_RD_O_20EC71_Rain peerChan 0 va_Btn1 single set
Nur beim Rain_device taucht peerChan im Dropdown auf
Bei getConfig wird mir das Feld PeerId aber weiterhin leer angezeigt:
Ich habe auch schon versucht die PeerId über die Console beim Hauptdevice zu setzen
(dropdown hat peerChan nicht), bekomme auch keine Fehlermeldung,
aber auch kein gefülltes Feld für die PeerId
Viele Grüße
trilu
Inzwischen hab ich meinen Sensor auch in Betrieb.
- beim Spannunganlegen erkenne ich im Event-Monitor keinen power-on event
- beim Spannunganlegen wird einmalig der Sensorstatur dry/rain geliefert
- beim Spannunganlegen wird die Heizung angeschaltet
- es gibt keine periodische rain/dry Meldung, sondern offenbar nur einen event beim Wechsel des Status
- in fhem funktioniert das Schalten derzeit noch falschrum (on schaltet die Heizung aus, und umgekehrt)
- laut Beschreibung kann man den Sensor mit einem Aktor peeren. Wenn ich nun davon ausgehe, dass der "sensor" Channel der Sensor ist, und die Heizung der Aktor, stellt sich mir die Frage, warum ich diese beiden Channels nicht miteinander peeren kann? Dann würde die Heizung bei Regen automatisch angehen. Das Abschalten würde so aber nicht funktionieren, weil laut Doku beim "trocken"-Melden kein Schaltbefehl generiert wird
Das sind die Punkte, die mir im Moment aufgefallen sind.
Ich habe mit eventMap rain und dry auf 50 und 0 gemappt und logge das Ganze in meine Wetterdaten. Dann wird der Regen (auf der Feuchtigkeitsskala) entsprechend im weblink dargestellt.
mir kommt grade die wahnwitzige Idee, hinter das Sichtfenster im Sensorgehäse einen Lichtsensor zu montieren und über ein dreiadriges Kabel gleich noch den Messwert ins Wohnungsinnere zu liefern :)
Platz genug ist ja in dem Gehäuse. Eigentlich hätte ja auch die verbaute CPU noch genügend Anschlüsse, um den Wert direkt zu erfassen. Aber das wird wohl an der Firmware scheitern. Oder irgendjemand schreibt mal eine eigene Firmware.
Firmware zu schreiben wäre nicht so schlimm. Die HW ist ja Arduino komp. und die Settings für das Funkmodul sind bekannt. Das grössere Problem wird die HM Kompatibilität sein. Also pair und peer usw.
Interesse hätte ich ja, aber das Protokoll aus den sourcen vom CUL nachzubauen bekomme ich nicht hin...
Hallo Trilu,
ich würde den Trigger aendert, da ein Wert mitkommt:
CUL_HM_HM_Sen_RD_O_20EC71_Rain trigger: 15:rain (to va_Btn1)
CUL_HM_HM_Sen_RD_O_20EC71_Rain trigger: 16:dry (to va_Btn1)
ZitatWarum die PeerId nicht angezeigt wird...
kannst du einmal ein getConfig mitloggen?
ZitatNur beim Rain_device taucht peerChan im Dropdown auf
korrekt. Die anderen kann man nicht peeren. Daher habe ich die anderen gesperrt.
ZitatIch habe auch schon versucht die PeerId über die Console beim Hauptdevice zu setzen
das macht keinen Sinn
a) nur Channels kann man peeren (manchmal ist eine 1-Kanal entity gleichzeitig device und channel, hier nicht)
b) das manuelle Setzen des Attributs ist in allen Entites möglich, empfehle ich aber generell nicht
c) man kann keine Peers anlegen, indem man das Attribut aendert, nur mit Kommando
@Udo
- kannst du die Message bei Spannungsanlegen loggen?
in fhem funktioniert das Schalten derzeit noch falsch rum
ups, drehe ich. Da hat HM die Werte getauscht ummit "on" = 0 zu starten - dünn...
- kannst du auch on-for-timer testen?
Zitatund die Heizung der Aktor, stellt sich mir die Frage, warum ich diese beiden Channels nicht miteinander peeren kann?
kannst du gerne probieren. Bitte mitloggen und dann getConfig. Ich denke wir haben das schon probiert.
Wenn es klappen sollte kann man mit der ConditionTable arbeiten - das könnte schon funktionieren... erst einmal peeren können
Interessanter Ansatz mit der FM. Wollt/könnt ihr die HM-devices flashen? könnte mich interessieren.
Gruss Martin
Hi Martin,
das ist der Log von einem getConfig auf den RainChannel
2013.08.01 09:39:44 1: HMLAN_Send: HMUSB S:S38D17052 stat: 00 t:00000000 d:01 r:38D17052 m:21 A001 631963 20EC71 01040000000001
2013.08.01 09:39:44 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:2205B3B7 d:FF r:FFB3 m:21 A010 20EC71 631963 0208002264230530060000
2013.08.01 09:39:44 1: HMLAN_Delay: HMUSB 20EC71
2013.08.01 09:39:44 1: HMLAN_Parse: HMUSB R:R38D17052 stat:0001 t:2205B3BC d:FF r:FFB3 m:21 A010 20EC71 631963 0208002264230530060000
2013.08.01 09:39:44 1: HMLAN_SdDly: HMUSB 20EC71
2013.08.01 09:39:44 1: HMLAN_Send: HMUSB S:S38D171F0 stat: 00 t:00000000 d:01 r:38D171F0 m:22 A001 631963 20EC71 01040000000004
2013.08.01 09:39:45 1: HMLAN_Parse: HMUSB R:E20EC71 stat:0000 t:2205B5BE d:FF r:FFB3 m:22 A010 20EC71 631963 0201000000
2013.08.01 09:39:45 1: HMLAN_Parse: HMUSB R:R38D171F0 stat:0001 t:2205B5C3 d:FF r:FFB3 m:22 A010 20EC71 631963 0201000000
2013.08.01 09:39:46 1: HMLAN_Send: HMUSB I:K
2013.08.01 09:39:46 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534665 d:1DAF52 O:631963 t:2205BD3E IDcnt:0001
Bzgl. der Firmware schreiben - hab noch mal nachgeschaut, hätte schwören können das ein Atmel 328 drauf ist - ist aber ein
STM8L151C8U6 drauf.
Spielt aber keine Rolle, auch für den gibt es einen C kompiler. Wobei mir Atmel lieber ist :-)
Die verbauten Funkmodule gibts auch einzeln, z.b. aus dem Fensterschalter Bausatz vom Max! System für 14 Euro.
Theoretisch müssten auch die PAN Stamps kompatibel sein. Das wäre vermutlich das günstigste, da so ein fertiges Modul 18,55$ +MwSt. kostet.
Ansteuerung der Funkmodule ist in den CUL Sourcen. Das ließe sich bestimmt adaptieren. Das größere Problem ist für mich wie das HM System funktioniert. Also welche Befehle können mit welchem Inhalt gesendet werden, welche Antworten werden erwartet, wie läuft das Pairen ab - wie werden Channels verbunden usw.
Momentan bin ich mit den RF12 Modulen von Jeelabs.org zu Gange. Das fhem modul für den USB Stick läuft. Senden/Empfangen klappt auch. Jetzt muss ich mich irgendwann mal an die Device Steuerung machen, also das Modul zwischen IO und fhem.
Ich würde aber auch das System wechseln wenn sich hier ein paar Mitstreiter finden um die panstamps "HM kompatibel" zu machen :-)
Viele Grüße
Horst
Zitat von: martinp876 schrieb am Do, 01 August 2013 08:33@Udo
- kannst du die Message bei Spannungsanlegen loggen?
ja, heute abend.
Zitat von: martinp876 schrieb am Do, 01 August 2013 08:33ups, drehe ich. Da hat HM die Werte getauscht ummit "on" = 0 zu starten - dünn...
- kannst du auch on-for-timer testen?
auch heute abend.
Zitatund die Heizung der Aktor, stellt sich mir die Frage, warum ich diese beiden Channels nicht miteinander peeren kann? [...]
kannst du gerne probieren.
Hab ich schon probiert - ohne Erfolg. Wenn ich das versuche, bekomme ich als Fehlermeldung immmer "bitte peer angeben" - irgendwo muss da in den beiden Channels etwas klemmen oder nicht zugelassen sein.
Das mit der Firmware auf der Sensorplatine sehe ich technisch auch nicht als großes Problem an. Die Schnittstellen zum Flashen sind ja sogar alle auf der Platine rausgeführt.
Bezüglich des Funkprotokolls finden sich sicher auch noch genug Informationen. So komplex ist der Baustein Sensor + Heizung an sich ja überhaupt nicht. Der Sensor läuft über einen ADC Wandler, die Heizung über einen simplen Digitalport als Schalter - mehr ist das nicht.
hier gibt es scheinbar den anfang einer homematic lib für atmega avrs: https://github.com/glueckkanja/AvrHmLibrary (//github.com/glueckkanja/AvrHmLibrary). damit und mit der cul firmware könnte jemand der erfahrung mit der ansteuerung des cc1101 hat vermutliche relativ schnell einen homematic (und fs20?) mode für die panstamps bauen.
nur die rf parameter setzen reicht leider nicht. das hatte ich schon mal versucht. irgendwo fehlt noch eine dumme kleinigkeit :)
gruss
andre
zu den Peers - ist mein Fehler, wird nicht abgefragt - mache ich heute (gerade keine Zeit... nachher)
Peers gibt es also nur beim rain-channel, es sei den betateilchen beweist, dass die Heizung auch etwas kann.
zu dem Eigenbau:
- du willst also einen eigenen controller bauen und dann sensoren adaptieren. Nicht schlecht. Interessiert mich auch.
zum Protokoll kann ich unterstützen, kein Problem. Du solltest dich dann eng an die HM vorgehensweise halten - die programmierung ist sehr strikt in Nutzung der register... Da kann ich dann etwas liefern - und meinen Senf dazugeben. Und wenn ich Zeit habe konnte ich mir auch einen bauen :-) Interessant wäre, es mit one-wire temperatur-sensoren zu koppeln... Die sind Billig und man könnte kluster von Fühlern bauen, die man über Funk abfragt... mal sehen.
Gruss Martin
habs doch gleich gefunden.
Du musst HMConfig Version 3568 nutzen (svn), dann werden die Peers gelesen.
http://sourceforge.net/p/fhem/code/3568/tree/trunk/fhem/FHEM/HMConfig.pm?format=raw (//sourceforge.net/p/fhem/code/3568/tree/trunk/fhem/FHEM/HMConfig.pm?format=raw)
oder bis morgen auf den Update warten
Gruss Martin
So wie ich das sehe gibt es mehrere Ansätze
Hier hat jemand begonnen die HW zu dokumentieren:
https://github.com/ccier/openhm/wiki/Devices (//github.com/ccier/openhm/wiki/Devices)
Das hier ist auch sehr interessant - anscheinend gibts da ein funktionierendes Grundgerüst:
http://www.mikrocontroller.net/topic/123275 (//www.mikrocontroller.net/topic/123275)
>Funktioniert soweit, allerdings noch ziemlich Beta. Spricht kein BidCos,
>sondern ein einfaches eigenes Protokoll (CA FE 01 SEQ[0..7] SEQ[8..15]
>CMD A B C), CMD z.b. F0 für button, dann A=button, B=state, C=toggle
>counter.
>Die Kommandos können mit CUL, HM-LAN-CFG etc. empfangen/gesendet werden.
Viele Grüße
Horst
Hi Martin,
das wäre echt Klasse wenn sich hier ein kleines Team finden lassen würde.
Eigentlich stehe ich nicht so auf HW Bastelei, aber der Ansatz mit den panstamps ist nicht so schlecht.
Ideen für eigene HW und Funktionen hätte ich reichlich. Was mich nur bei den meisten Lösungen stört ist
die Inkompatibilität. PanStamp mit swap ist bestimmt klasse, aber lässt sich halt nicht mit einem HM Schalter peeren.
D.h. das Zusammenspiel muss immer über fhem laufen, was ok ist, solange fhem läuft :-)
Ich hätte halt gerne die Flexibilität von einem System wie PanStamp mit der Möglichkeit Geräte zusammen zu schalten
ohne das ein Server dazwischen sein muss.
Wenn wir zusammen eine HM komp. Arduino-Lib hinbekommen hätten wir genau diese Flexibilität. Man kann Basteln oder
vorhandene HM Geräte erweitern oder eigene Geräte mit schicken HM Fernbedienungen, Schaltern, etc. peeren.
Ich werde mal die test.c aus diesem Thread am Wochenende testen und schauen ob ich eine minimal HW zum testen hinbekomme.
http://www.mikrocontroller.net/topic/123275 (//www.mikrocontroller.net/topic/123275)
Viele Grüße
Horst
hattest du den link in mein post oben gesehen?
diese lib auf einem panstamp wäre ziemlich genau das was du möchtest ...
gruss
andre
ja, habe ich! Danke dafür.
Ich werde da auch ein wenig "abkupfern". Mein Problem ist, ich bin mehr der Trial and Error Mensch.
Meine Vorgehensweise ist mehr - brauchbares Grundgerüst, so dass ich sehe die Funkstrecke steht
und dann Funktion für Funktion dazu bauen.
Heisst - erste Hürde, funktionierende Hardware mit Funkmodul an den Arduino.
Dann stabile Sende und Empfangsroutine
Danach Pairen
Dann Kommunikation zwischen CUL und eigener HW
- ACK/NACK Handling
- Register, etc....
Jemand Lust mitzumachen?
panstamps habe ich hier. wenn jemand das funk modul so initialisiert das es hm (und vielleicht fs20) sendet und empfängt mache ich gerne mit und baue das in dem modem sketch und das panstamp modul ein. dann könnte man einen panstick statt einem cul verwenden. bei der sketch seite für die panstamps mache ich auch gerne mit.
nur beim ans laufen bekommen des rf teils bin ich keine hilfe. einfach register setzen hatte nicht gereicht. das hatte ich wie gesagt schon probiert.
gruss
andre
Hi,
mal eine dumme Frage:
- wo kann man die panstamps kaufen? Auf der webseite habe ich keinen Link gesehen, auch keine Preisliste
- Welchen Adapter nutzt ihr zum Prommen? Welches der Arduino boards ist hinreichend?
- Läuft arduino auf LINUX UND Windows?
Gruss Martin
das waren vier und keine davon dumm :)
- auf panstamp.com gibt es einen link zu shop. da stehen auch preise.
- das einfachste ist einen panstick mit zu bestellen. da kommt der panstamp zum programmieren drauf und der ist hinterher mit einem panstamp auch das interface zu fhem.
- du brauchst keinen arduino zusätzlich. ein panstamp ist ein arduino plus funkmodul.
die ide läuft auf linux, mac und windows.
gruss
andre
die alternative zum testen ist
1 Arduino nano oder mini pro
+ 1 Funkmodul aus einem HM oder Max Device
Der PanStamp kostet 18$ + MwST + 10$ Versand
Programmieren kann man die Dinger auch über ein kleines FTDI Modul USB zu Seriel
oder jedem anderen USB zu TTL Umsetzer PL2023 oder...
Nur zum testen ist mir der PanStamp zu teuer - ich werde wie schon geschrieben am Wochenende mal mit einem
Funkmodul aus einem Fensterkontakt vom MAX! testen. Arduino Mini's hab ich einige rumfliegen.
Wenn das klappt hol ich mir ein oder zwei von diesen PanStamps, wenn du willst können wir gerne zusammen bestellen.
Die Arduino Oberfläche läuft auf Windows und Linux - du kannst die Dinger aber auch mit Visual Studio + Plugin
oder Eclipse mit PlugIn programmieren.
Ob PanStamp auch die Arduino Oberfläche nutzt, weiss ich gar nicht. Ich will aber das PanStamp Framework nicht nutzen.
Ich will ja nicht Swap sondern Bidcos :-)
Oh, die Frage des Programmierens übersehen. Arduino hat einen seriellen Bootloader im Device. Der Bootloader stellt
eine serielle Schnittstelle zum Programmieren zur Verfügung. Falls du den Bootloader tauschen willst, benötigst du einen Programmieradapter mit ISP Schnittstelle. Zum Testen und Debuggen reicht ein serieller USB nach TTL Adapter.
Beim Arduino Nano ist der USB Adapter bereits eingebaut. Bei den PanStamps und Arduino Mini Pro steht der TTL Pegel an.
FTDI - Adapter sind gut geeignet, da der DTR den Arduino in den Bootloader Mode schalten kann.
Bei der Arduino Geschichte bin ich auch mit dabei - ich hab auch noch ein paar hier rumliegen :)
Hi Martin,
ich glaube, Du hast die On/Off settings in 10_CUL_HM an der falschen Stelle geändert. Mit folgender
Änderung geht es:
428c428
< ,"HM-Sen-RD-O02" =>{"00"=>"on" ,"C8"=>"off"}
---
> ,"HM-Sen-RD-O02" =>{"00"=>"off" ,"C8"=>"on"}
2221,2223d2220
< elsif ($md eq "HM-Sen-RD-O"){# on<->off for this sensor...
< $lvl = ($lvl eq "00")?"C8":"00";
< }
2241c2238
< my $lvl = ($md eq "HM-Sen-RD-O")?"00":"C8";
---
> my $lvl = "C8";
Toggle schaltet nur ein, weil dem Channel das Attribute "level" fehlt und CUL_HM_getChnLvl daher immer 0
zurück liefert. on-for-timer geht prinzipiell, zeigt aber irgendwie kein lineares Verhalten. 30s sind
real ehe 3s, 50s deutlich mehr als 50s.
Gruß, Marc
und ich habe die aktuellen HM-Files aus dem SVN eingespielt und bekomme jetzt nur noch response-timeouts beim Regensensor...
Kann ich nicht bestätigen. Ich habe auch den aktuellen SVN Stand eingespielt und es fuktioniert
mit obgigen Einschränkungenm bzw. benötigten Fixes.
Gruß, Marc
tja, ich hab jetzt wieder den Stand von gestern eingespielt - und alles läuft wie es soll.
edit: funktioniert jetzt auch mit den SVN-Files - keine Ahnung was da vorhin los war.
Kann eigentlich nicht sein. Wenn Du einen Diff machst, wirst Du sehen, dass sich
seit gestern neben der Umbenennung von ein paar Variablen nur in Sachen RD on/off
was geändert hat. Letzteres funktionierte gestern nicht wie man es erwarten
würde und heute auch nicht . Allein das Fehlerbild sieht etwas anders aus ...
Zitat von: marc2 schrieb am Do, 01 August 2013 22:11Kann eigentlich nicht sein.
eine typische Support-Antwort ...
Mit Blick auf den Diff (//sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/10_CUL_HM.pm?diff=51b78df35fcbc96f6b6b9d33:3559) kann es nicht sein ...
@Martin
Während des Einschaltvorganges scheint der RD leider kein "PowerOn" zu senden. Er senden
nur zwei Nachrichten, "dry" und "heating on":
2013.08.01 22:31:09 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:24AC573E d:FF r:FFC1 m:00 A610 20ECC4 F14321 0602C800
2013.08.01 22:31:14 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:24AC6B6C d:FF r:FFC6 m:01 A610 20ECC4 F14321 06010000
2013.08.01 22:31:15 1: HMLAN_Send: HMLAN1 I:K
Entsprechend wird es mit dem Trigger zum Abschalten der Heizung nach Starten des Sensors wohl schwierig.
Gruß, Marc
Hi,
das hatte ich falsch verstanden. Es war kein Fehler beim Heizung-einschalten sondern nur in der Anzeige/parsen. Die hatte ich falsch :-(
Beruhigend, dass HM on und off nicht dreht.
@Marc - korrekt, dann sind das sie Aenderungen (bei on-fortimer wird es dann gar kein $lvl mehr geben, hätte ich nur zumDrehen gebraucht)
V 3574
Gruss Martin
@Marc,
schade, dass es keine powerOn message gibt.
Ich sehe nur einen Weg, powerOn zu erkennen: Wenn der message-zähler mit 00 startet und die beiden Stati mit 00 und 01 kommen. Ist nicht schön aber sollte relativ sicher funktionieren.
Wie wichtig ist euch ein default "heating off" nach power-on?
Einbauen werden ich es wenn gewünscht und wenn die tests mit dem peeren des "heating-actors" abgeschlossen sind. Dann käme evtl noch die Regenautomatik dauz (falls peeren nicht klappt)
Gruss Martin
Hi Martin,
wenn es nicht zu viel Arbeit macht wäre so ein default heating off schon gut.
Das Ding zieht immerhin zwei Watt und bei der momentanen Wetterlage ist das rausgeschmissenes Geld :-))))
Hab mal ein Messgerät ran gehängt - 0,4W ohne Heizung, 2,4 Watt mit Heizung...
Viele Grüße und Danke
Horst
Hallo Martin,
sehe ich wie Horst, die Heizung verbrät deutlich Leistung. Am besten wäre vielleicht eine Automatik,
die einfach bei "dry" die Heizung abschaltet, und bei "rain" einschaltet. Am besten wäre es,
wenn man die Automatic per Attribut abschaltet können. Wenn das zuviel Aufwand ist, kann man
sich das ja auch einfach per notify und eingenem Attribut selber bauen. Kostet halt nur ein
wenig mehr CPU ...
Gruß, Marc
Hi,
nun, noch nicht fertig getestet (habe keinen Sensor...) im Anhang ein Versuch. Noch ohne Doku.
Im heating sensor kann man das Attribut
attr heating param offAtPon
attr heating param onAtRain
attr heating param offAtPon,onAtRain
setzen.
Nach powerOn sollte jetzt auch das Reading "powerOn" kommen. Die Heizung entsprechend dem gesetztem Parameter gesteuert werden.
Man kann die Heizung natürlich noch manuell anschalten aber der nächste trigger sollte dies überschreiben.
onAtRain schaltet bei Rain "on" und bei dry "off"
Bitte Rückmeldung
Gruss Martin
Hallo Martin,
1. Test mit Deiner Testversion, ohne jegliche neue Attribute
2013.08.02 12:31:32.890 1: HMLAN_Send: HMUSB I:K
2013.08.02 12:31:32.904 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534751 d:1DAFAC O:127000 t:12B34C93 IDcnt:0006
2013.08.02 12:31:34.119 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:12B3513C d:FF r:FFBE m:DC A258 1D919A 1DA1A9 0000
2013.08.02 12:31:34.330 1: HMLAN_Parse: HMUSB R:E1DA1A9 stat:0000 t:12B351BF d:FF r:FFBE m:DC 8202 1DA1A9 1D919A 0101000038
2013.08.02 12:31:51.242 1: HMLAN_Parse: HMUSB R:E20EC04 stat:0000 t:12B39427 d:FF r:FFB1 m:00 A610 20EC04 127000 0602C800
2013.08.02 12:31:56.393 1: HMLAN_Parse: HMUSB R:E20EC04 stat:0000 t:12B3A83F d:FF r:FFAC m:01 A610 20EC04 127000 06010000
2013.08.02 12:31:57.895 1: HMLAN_Send: HMUSB I:K
2013.08.02 12:31:58.185 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534751 d:1DAFAC O:127000 t:12B3AF4C IDcnt:0006
2013.08.02 12:32:22.898 1: HMLAN_Send: HMUSB I:K
2013.08.02 12:32:22.924 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534751 d:1DAFAC O:127000 t:12B40FEB IDcnt:0006
Ein neues Reading poweron kann ich nicht finden,
die Parameter lassen sich nicht setzen, weil das Attribut "param" unbekannt ist.
out_Regen_Heizung: unknown attribute param, choose one of
muss param erst noch als globales userattr definiert werden?
so, nun hab ich mal param global definiert - keine Änderung beim Anlegen der Spannung. Die Heizung bleibt an.
Übrigens:
Wenn ich das peeren der beiden internen Channels probiere, bekomme ich im Log folgende Fehlermeldung:
Argument "out_Regen_Heizung" isn't numeric in numeric lt (<) at ./FHEM/10_CUL_HM.pm line 2657.
Argument "20EC0402" isn't numeric in numeric lt (<) at ./FHEM/10_CUL_HM.pm line 2657.
Wie man sieht, ist es egal, ob man den Namen oder die Channel-ID verwendet.
Hi,
kann eigentlich nicht sein.
Das Attribut param ist zu 100% drin.
Ob das reading mit powerOn funktioniert konnte ich nicht testen - aber wenn schon das Attribut fehlt hast du nicht mein neues File. Hast du das aus dem Post genommen?
Habe es noch einmal kontrolliert - das File ist mindestens soweit korrekt
Gruss Martin
Ich hatte zwar schon das Paket hier aus dem Thread genommen, aber der doofe Google Chrome macht daraus immer ein .pl anstatt einem .pm File - ich hatte es nicht umbenannt.
2013-08-02 14:49:02.839 CUL_HM out_Regen_Heizung on
2013-08-02 14:49:08.046 CUL_HM out_Regen_Sensor trigger: 1:0 (to out_Regen)
Aber die Heizung wird trotz jetzt vorhandenem Parameter offAtPon nicht abgeschaltet.
Vorher war die Meldung vom Sensor nach dem einschalten übrigens "dry" oder "rain" und nicht trigger.
Internals:
DEF 20EC0402
EVENTS 4
NAME out_Regen_Heizung
NR 354
STATE on
TYPE CUL_HM
chanNo 02
device out_Regen
Readings:
2013-08-02 14:51:14 CommandAccepted yes
2013-08-02 14:51:48 state on
Helper:
pOn 1
Param:
offAtPon 1
Role:
chn 1
Attributes:
expert 2_full
group Balkon Wetter
model HM-Sen-RD-O
param offAtPon
peerIDs
room 20_Wetter,17_Balkon
Internals:
DEF 20EC0401
EVENTS 4
NAME out_Regen_Sensor
NR 353
STATE 0
TYPE CUL_HM
chanNo 01
device out_Regen
Readings:
2013-08-02 14:48:12 R-eventFilterTime 0.5 s
2013-08-02 14:48:12 R-transmitTryMax 6
2013-08-02 14:48:12 RegL_01: 08:00 22:64 23:05 30:06 00:00
2013-08-02 14:52:01 state dry
2013-08-02 14:51:53 trigger 1:dry (to out_Regen)
Helper:
getCfgList all
getCfgListNo 4
Role:
chn 1
Shadowreg:
Attributes:
eventMap rain:50 dry:0
expert 2_full
group Balkon Wetter
model HM-Sen-RD-O
peerIDs
room 20_Wetter,17_Balkon
Internals:
DEF 20EC04
EVENTS 3
HMUSB_MSGCNT 31
HMUSB_RAWMSG E20EC04,0000,1333E963,FF,FFAF,02A61020EC0412700006010000
HMUSB_RSSI -81
HMUSB_TIME 2013-08-02 14:52:01
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 31
NAME out_Regen
NR 352
STATE CMDs_done_events:5
TYPE CUL_HM
channel_01 out_Regen_Sensor
channel_02 out_Regen_Heizung
lastMsg No:02 - t:10 s:20EC04 d:127000 06010000
protLastRcv 2013-08-02 14:52:01
protResnd 4 last_at:2013-08-02 14:48:29
protResndFail 1 last_at:2013-08-02 14:48:33
protSnd 5 last_at:2013-08-02 14:51:09
protState CMDs_done_events:5
rssi_HMUSB avg:-70.5 min:-71 max:-70 lst:-70 cnt:2
rssi_at_HMUSB avg:-82.48 min:-86 max:-78 lst:-81 cnt:31
Readings:
2013-08-02 12:55:01 CommandAccepted yes
2013-08-02 14:48:11 PairedTo 0x127000
2013-08-02 14:48:11 R-intKeyVisib invisib
2013-08-02 14:48:11 R-localResDis off
2013-08-02 14:48:11 R-pairCentral 0x127000
2013-08-02 14:48:11 R-transmDevTryMax 6
2013-08-02 14:48:11 RegL_00: 02:01 0A:12 0B:70 0C:00 14:06 18:00 00:00
2013-08-02 14:52:01 state CMDs_done_events:5
Helper:
burstEvtCnt 5
mId 00A7
rxType 1
Respwait:
Role:
dev 1
Rssi:
Hmusb:
avg -70.5
cnt 2
lst -70
max -70
min -71
At_hmusb:
avg -82.4838709677419
cnt 31
lst -81
max -78
min -86
Shadowreg:
Attributes:
expert 2_full
firmware 1.3
group Balkon Wetter
model HM-Sen-RD-O
peerIDs
room 20_Wetter,17_Balkon
serialNr KEQ0117003
subType sensRain
webCmd getConfig
ok, jetzt war mein Fehlern, falscher Kanal...
versuch den einmal
2013-08-02 15:05:26.648 CUL_HM out_Regen_Heizung on
2013-08-02 15:05:31.823 CUL_HM out_Regen_Sensor trigger: 1:0 (to out_Regen)
2013-08-02 15:05:39.965 CUL_HM out_Regen_Sensor 0
aber die Heizung bleibt an.
2013.08.02 15:05:26.587 1: HMLAN_Parse: HMUSB R:E20EC04 stat:0000 t:134030EF d:FF r:FFAF m:00 A610 20EC04 127000 0602C800
2013.08.02 15:05:31.708 1: HMLAN_Parse: HMUSB R:E20EC04 stat:0000 t:13404505 d:FF r:FFB2 m:01 A441 20EC04 20EC04 010100
2013.08.02 15:05:31.996 1: HMLAN_Parse: HMUSB R:E20EC04 stat:0000 t:13404615 d:FF r:FFB1 m:01 A041 20EC04 20EC04 010100
2013.08.02 15:05:33.532 1: HMLAN_Parse: HMUSB R:E20EC04 stat:0000 t:13404C24 d:FF r:FFAE m:01 A041 20EC04 20EC04 010100
2013.08.02 15:05:35.051 1: HMLAN_Send: HMUSB I:K
2013.08.02 15:05:35.516 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534751 d:1DAFAC O:127000 t:134053E6 IDcnt:0003
2013.08.02 15:05:35.580 1: HMLAN_Parse: HMUSB R:E20EC04 stat:0000 t:13405417 d:FF r:FFB2 m:01 A041 20EC04 20EC04 010100
2013.08.02 15:05:39.644 1: HMLAN_Parse: HMUSB R:E20EC04 stat:0000 t:134063EB d:FF r:FFAD m:01 A041 20EC04 20EC04 010100
2013.08.02 15:05:39.868 1: HMLAN_Parse: HMUSB R:E20EC04 stat:0000 t:134064CF d:FF r:FFAF m:02 A610 20EC04 127000 06010000
2013.08.02 15:06:00.055 1: HMLAN_Send: HMUSB I:K
2013-08-02 15:25:18.900 CUL_HM out_Regen_Sensor trigger: 2:50 (to out_Regen)
2013-08-02 15:25:27.131 CUL_HM out_Regen_Sensor 50
2013-08-02 15:25:27.532 CUL_HM out_Regen_Heizung on
Zumindest das onAtRain scheint zu funktionieren. Und wenn der Sensor dann wieder trocken ist:
2013-08-02 15:26:33.304 CUL_HM out_Regen_Sensor 0
2013-08-02 15:26:34.482 CUL_HM out_Regen_Heizung off
Das heißt doch, wenn der Parameter "onAtRain" gesetzt ist und es nicht regnet, wenn der Sensor Spannung bekommt, müsste die Heizung ausgehen? Mal testen...
2013-08-02 15:29:38.409 CUL_HM out_Regen_Heizung on
2013-08-02 15:29:44.414 CUL_HM out_Regen_Sensor trigger: 1:0 (to out_Regen)
2013-08-02 15:29:51.809 CUL_HM out_Regen_Sensor 0
2013-08-02 15:29:52.198 CUL_HM out_Regen_Heizung off
funktioniert :)
was ist eigentlich localResDis
und warum geht trigger an das Device und nicht an den Heizungs-Channel?
registerkurzbeschreibung ist in "get regList" - wie ich es verstanden habe...:
0: localResDis | - to - | |exp| local reset disable options:on,off
sollte eben den reset am Device (local) abschalten. Also kein Reset mehr, wenn man lange anlernen drückt.
Zitatund warum geht trigger an das Device und nicht an den Heizungs-Channel?
weil der heatChannel sich nicht peeren lässt. Du kannst gerne noch einen Versuch machen und den Channel mit irgendeinem Sensor peeren (z.B. dem rain channel oder einem Taster). danach - sollte es funktioniert haben - ein getConfig. Dann bitte mitschneiden, damit ich es nachvollziehen kann.
Gruss Martin
Nachtrag: powerOn ist auch gekommen? Sollte ich dem Device zuweisen... ist sicher noch falsch.
Zitat von: martinp876 schrieb am Fr, 02 August 2013 16:40registerkurzbeschreibung ist in "get regList" - wie ich es verstanden habe...:
...
sollte eben den reset am Device (local) abschalten. Also kein Reset mehr, wenn man lange anlernen drückt.
Achso... um die Konfigurationstaste drücken zu können, muss man übrigens das Gerät zerlegen, wenn man es einmal in Betrieb hat. Die Taste ist von außen nicht zugänglich. Man braucht die Taste aber nicht wirklich, wenn man irgendwas machen will. Ein getconfig oder auch jeder andere Befehl wird sofort ausgeführt, auch ohne Taste drücken.
ZitatNachtrag: powerOn ist auch gekommen? Sollte ich dem Device zuweisen... ist sicher noch falsch.
ich habe bisher kein powerOn gesehen.
ok, ich sehen. Der Sensor schickt (leider ) erst die Trigger und dann den Status des Rain channels. Da muss ich umbauen - schade, wäre zu einfach gewesen.
Gruss Martin
dann sollte es dies gewesen sein Version 3579 incl powerOn für Device und heating off at powerOn wenn "programmiert"
Mal so gesagt: wenn man schon Automatikbetrieb will, funktioniert das doch mit onAtRain ganz super. Nach dem Anlegen der Spannung dauert es eben ein paar Sekunden, bis die erste Sensormeldung kommt, und dann wird korrekt geschaltet. MIR reicht das eigentlich so als Funktionalität. So oft wird die Spannung ja nicht getrennt.
Moin !
Also ein PowerOn sehe mit der Version 3579 ehrlich gesagt auch nicht. Macht aber nichts,
da die Steuerung über onAtRain wunderbar funktioniert ! Wie immer vielen Dank !
Mir ist gerade noch aufgefallen, dass "toggle" nach wie vor nur an, aber nicht abschaltet.
Das Setzen des level Readings behebt das Problem:
*** 10_CUL_HM.pm 2013-08-02 21:19:58.000000000 +0200
--- /tmp/10_CUL_HM.pm 2013-08-02 23:06:41.081401495 +0200
*************** sub CUL_HM_Parse($$) {##################
*** 880,885 ****
--- 880,886 ----
$val = hex($val)/2;
}
push @event, "state:$val";
+ push @event, "level:".($val eq "off"?"0 %":"100 %");
if ($mNo eq "00" && $chn eq "02" && $val eq "on"){
$hHash->{helper}{pOn} = 1;
Folgenden Schönheitsfehler könnte man noch beheben:
Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 3275.
Use of uninitialized value $_ in hash element at ./FHEM/10_CUL_HM.pm line 4068.
Er kommt nach Anschalten des Sensors, sobald dieser erstmalig "dry" meldet.
Gruß, Marc
2013-08-02 23:12:42 CUL_HM out_Regen_Sensor trigger: 1:0 (to out_Regen)
2013-08-02 23:12:42 CUL_HM out_Regen powerOn:
2013-08-02 23:12:52 CUL_HM out_Regen_Sensor 0
2013-08-02 23:12:53 CUL_HM out_Regen_Heizung off
Da taucht das powerOn schon auf... sieht aber trotzdem komisch aus. Und als Reading? negativ...
Hmm, sehe ich deswegen nicht, weil das Device grundsätzlich NACK sendet. Die beiden
Channels funktionieren hingegen wunderbar. Habe schon alles einmal neu gepairt, allerdings
ohne Verbesserung. Hier der Mittschnitt eines "statusRequests" gegen das Device:
2013.08.02 23:52:13.664 1: HMLAN_Send: HMLAN1 S:+20ECC4,00,01,
2013.08.02 23:52:13.666 1: HMLAN_Send: HMLAN1 S:S4104469F stat: 00 t:00000000 d:01 r:4104469F m:0A A001 F14321 20ECC4 010E
2013.08.02 23:52:13.823 1: HMLAN_Parse: HMLAN1 R:R4104469F stat:0001 t:2A1D17F9 d:FF r:FFC6 m:0A 8002 20ECC4 F14321 80
2013.08.02 23:52:13.836 1: HMLAN_Send: HMLAN1 S:+20ECC4,00,01,
2013.08.02 23:52:13.838 1: HMLAN_Send: HMLAN1 S:S4104474B stat: 00 t:00000000 d:01 r:4104474B m:0B A001 F14321 20ECC4 020E
2013.08.02 23:52:14.224 1: HMLAN_Parse: HMLAN1 R:R4104474B stat:0001 t:2A1D1989 d:FF r:FFC7 m:0B 8002 20ECC4 F14321 80
Gruß, Marc
powerOn wird immer als Reading gemeldet. Wie sonst? Erzeugt natürlich auch einen Event.
@betateilchen: kanns funktioniert der statuerequest auf beiden Kanäle?
@marc: kannst du einmal die rohmessages beim poweron mitschneiden? Bisher kenne ich nur 2 Verhalten beim starten. Könnte sein, dass deins eine3. Variante hat.
Und richtig, toggel nutzt level zum Schalten
Nachtrag
@Marc: hast du alle 3 entities definiert?
Zitat$name in concatenation (.) or string at fhem.pl line 3275
scheint einer zu fehlen.
Hallo Martin,
es sind das Device und beide Channels definiert:
define Regensensor CUL_HM 20ECC4
attr Regensensor .devInfo 040101
attr Regensensor .stc 70
attr Regensensor IODev HMLAN1
attr Regensensor expert 2_full
attr Regensensor firmware 1.3
attr Regensensor model HM-Sen-RD-O
attr Regensensor peerIDs
attr Regensensor serialNr KEQ0117188
attr Regensensor subType sensRain
attr Regensensor webCmd getConfig
define FileLog_Regensensor FileLog ./log/Regensensor-%Y-%m.log Regensensor
attr FileLog_Regensensor logtype text
attr FileLog_Regensensor room Logfiles
define Regensensor_Status CUL_HM 20ECC401
attr Regensensor_Status IODev HMLAN1
attr Regensensor_Status expert 1
attr Regensensor_Status model HM-Sen-RD-O
attr Regensensor_Status peerIDs
attr Regensensor_Status room Aussen
define FileLog_Regensensor_Status FileLog ./log/Regensensor_Status-%Y-%m.log Regensensor_Status
attr FileLog_Regensensor_Status logtype text
attr FileLog_Regensensor_Status room Logfiles
define Heizung_Regensensor CUL_HM 20ECC402
attr Heizung_Regensensor IODev HMLAN1
attr Heizung_Regensensor expert 2_full
attr Heizung_Regensensor icon icoHEIZUNG
attr Heizung_Regensensor model HM-Sen-RD-O
attr Heizung_Regensensor param offAtPon,onAtRain
attr Heizung_Regensensor peerIDs
attr Heizung_Regensensor room Aussen
attr Heizung_Regensensor webCmd toggle:on:off:statusRequest
define FileLog_Heizung_Regensensor FileLog ./log/Heizung_Regensensor-%Y-%m.log Heizung_Regensensor
attr FileLog_Heizung_Regensensor logtype text
attr FileLog_Heizung_Regensensor room Logfiles
Hier das log beim vom Starten des Sensors:
2013.08.03 08:51:32 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2C0AE8AD d:FF r:FFC9 m:00 A610 20ECC4 F14321 0602C800
2013.08.03 08:51:32 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:03217344 d:FF r:FFB5 m:00 A610 20ECC4 F14321 0602C800
2013.08.03 08:51:32 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:032173BD d:FF r:FFBB m:00 8002 F14321 20ECC4 00
2013.08.03 08:51:32 1: HMLAN_Send: HMUSB1 I:K
2013.08.03 08:51:32 1: HMLAN_Parse: HMUSB1 V:03BC sNo:JEQ0534837 d:1DB057 O:F14321 t:03217455 IDcnt:0003
2013.08.03 08:51:33 1: HMLAN_Send: HMLAN1 I:K
2013.08.03 08:51:33 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315301 d:1C673E O:F14321 t:2C0AED5E IDcnt:0006
2013.08.03 08:51:37 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2C0AFCDF d:FF r:FFC9 m:01 A610 20ECC4 F14321 06010000
2013.08.03 08:51:37 1: readingsUpdate(,powerOn,) missed to call readingsBeginUpdate first.
2013.08.03 08:51:37 1: HMLAN_Send: HMLAN1 S:S42F21D29 stat: 00 t:00000000 d:01 r:42F21D29 m:12 A011 F14321 20ECC4 0202000000
2013.08.03 08:51:38 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:03218775 d:FF r:FFB5 m:01 A610 20ECC4 F14321 06010000
2013.08.03 08:51:38 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:032187EE d:FF r:FFBB m:01 8002 F14321 20ECC4 00
2013.08.03 08:51:38 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:032188FF d:FF r:FFBB m:12 A011 F14321 20ECC4 0202000000
2013.08.03 08:51:38 1: HMLAN_Parse: HMLAN1 R:R42F21D29 stat:0001 t:2C0AFEEB d:FF r:FFC9 m:12 8002 20ECC4 F14321 0102000030
2013.08.03 08:51:38 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:0321897C d:FF r:FFB5 m:12 8002 20ECC4 F14321 0102000030
Gruß, Marc
Seit der 3579 bekomme ich keine Logmeldung mehr, wenn der Sensor REGEN erkennt. Die Logmeldung kommt aber, wenn wieder TROCKEN ist. Das Schalten bei Regen funktioniert aber einwandfrei. Geht gar nicht, weil ich diese Events zum Plotten der Regenzeiten brauche.
statusRequest auf die Channels funktionieren nicht, da bekomme ich auch nur NACK im Device.
hm - viele Details. Werde daran arbeiten
@mark: offensichtlich erkenne ich powerOn aber das schreiben des Readings geht daneben.
Das Ausschalten der Heizung funktioniert aber. Es fehlt ausschliesslich die powerOn Meldung.
n.b. (unwichtig, nur Hinweis):
- das Attribut "IODev" für channels macht übrigens keinen Sinn. Nur Devices machen IO
- attr "expert", wenn du es im Device definiert hast ist auch für den Channel gültig.
Wenn du es auch im channel setzt kannst du den Wert des Device überschreiben. In diesem Fall
brauchst du es also nicht in den Channels (halt, bei rain hast du es auf '1' gesetzt!
Übrigens, (aber das kennt ihr sicher schon), kann man bei 'room' eine liste von räumen eintragen, komma getrennt.
Sieht bei mit so aus
attr LichtDev room CUL_HM,device,licht,wohnzimmer
attr LichtDev_ch1 room CUL_HM,licht,wohnzimmer
attr LichtDev_ch2 room CUL_HM,licht,flur,LEDleuchten
ist m.E. exterm hilfreich um im web-interface schnell zu navigieren. Eigentlich ist room ein "groups".
Ich denke daran das Attribut "peerIDs" aus reinen Devices zu löschen.
Ausserdem sollte ich wohl das Kommando "statusRequest" bei einigen channels sperren.
@betateilchen:
Seit der 3579 bekomme ich keine Logmeldung mehr, wenn der Sensor REGEN erkennt. Die Logmeldung kommt aber, wenn wieder TROCKEN ist. Das Schalten bei Regen funktioniert aber einwandfrei. Geht gar nicht, weil ich diese Events zum Plotten der Regenzeiten brauche.
ist klar, dass es kommen muss.
Der trigger/event kommt also nur bei Dry? oder nur das erste mal bei "rain" nicht? hast du ein event-on-change gesetzt?
Gruss Martin
Nachtrag @Marc: hast du die neuste Version? bei powerOn mache ich keinen bulkUpdate. Die Fehlermeldung aus fhem.pl ist seltsam an dieser Stelle.
Hallo Martin,
die Logmeldung kommt bei "rain" kommt gar nicht mehr.
Ich denke daran das Attribut "peerIDs" aus reinen Devices zu löschen.
bitte nicht...
# $Id: 10_CUL_HM.pm 3586 2013-08-03 06:29:04Z martinp876 $
2013-08-03 11:09:44 CUL_HM out_Regen_Sensor trigger: 16:25 (to out_Regen)
2013-08-03 11:09:52 CUL_HM out_Regen_Sensor 25
2013-08-03 11:09:52 CUL_HM out_Regen_Sensor level: 100 %
2013-08-03 11:09:53 CUL_HM out_Regen_Heizung on
2013-08-03 11:09:53 CUL_HM out_Regen_Heizung level: 100 %
Und der fehlende Logeintrag war ein Fehler auf meiner Seite. Ich hatte gestern die eventMap von 0:50 auf 0:25 geändert und vergessen, die FileLog-Def anzupassen.
ok, dann sind wir soweit klar.
statusRequest noch entfernen.
Warum willst du peerIDs auch bei devices? Ist irreführend und unbrauchbar. Macht es etwas besonderes bei dir? Der Parameter gehört in erster Linie CUL_HM und ist eigentlich "intern".
Eigentilch sollte ich ihn unsichtbar machen, der User hat peerList zur Lesbarkeit
Gruss Martin
Zitat von: martinp876 schrieb am Sa, 03 August 2013 11:42Warum willst du peerIDs auch bei devices?
Weil ich da durchaus erkennen kann, ob ein peering funktioniert hat, z.B. beim Tür/Fensterkontakt RHS. Und weil manchmal die Id einfach mehr hilft als der Name des peers - vor allem bei der Fehlersuche.
(http://up.picr.de/15378768op.png)
Das powerOn ist aber aktuell noch nicht eingebaut, oder?
Ich denke, da ist ein missverständniss.
Das Attribut peerIDs wird nicht eliminiert werden. Das ist wichtig, da ich z.B. bei remotes,... es nicht einfach abfragen kann. Somit kann ich es "speichern" und es bleibt über reboot bestehen. Wichtig sind hier auch die IDs da ich somit von renames unabhängig bin. peerList wird immer nur eine Ableitung von peerIDs bleiben.
Eliminieren will ich peerIDs ausschliesslich aus "devices", nicht aber aus "channels". Devices haben keine peers, somit ist das Attribut sinnlos. Das Attribut kann ich nicht ausblenden, aber das Setzen 'rejecten' - das ist der Plan.
Ich denke dass du somit und in dieser Form nichts dagegen hast - korrekt?
Noch ein weiterer Plan:
da peerList in den Readings nicht "verlinkt" wird (verlinken habe ich nur für attribute und 'allgemein' eingebaut könnte es sinnvoll sein die peerList nach 'allgemein' zu verschieben. Dann hätte man einen Link zu allen peers... werde ich einmal testen.
Das verlinken in Readings einzubauen ist möglich - da es aber alle Familien betrifft will ich es nicht eigentlich machen.
Gruss Martin
Zitat von: martinp876 schrieb am Sa, 03 August 2013 12:33Ich denke dass du somit und in dieser Form nichts dagegen hast - korrekt?
wenn ich Deinen beschriebenen Plan auch nur ansatzweise verstehen würde, könnte ich Dir diese Frage sicher beantworten.
Wenn Du Dir den oben angehängten Screenshot eines DEVICES anschaust, steht da eindeutig eine peerId drin. Dass dieser Türdrehgriff letztendlich über seinen Channel gepeert ist, ist auch klar. Aber dieser Channel taucht per default einfach nirgends auf - und dann hat man keinen Channel zur Anzeige, in dem man die peerId sehen würde.
also: es gibt devices und channels. Wenn ein Device nur einen Channel hat (oder auch so) kann man channel 01 UND device in einer Entity abbilden - ist so üblich.
Deine Entity ist zugleich channel und device. Es gibt hier keinen Eintrag "channel_01" oder? Somit bleibt alles erhalten. Aendern wird es sich nur wenn du einen 2-schalter Switch hast und 3 entities (device, channel01 und channel 02). peerIDs gibt es dann nicht im Device.
Noch einmal mit anderen Worten: attr "peerIDs" ist nur verboten für "nur-device-entities". "device-und-channel-entities" sind auch channels, dürfen also.
solltest du eine "device-und-channel-entity" haben und nun channel_01 definieren (als eigene Entity) verschiebe ich attr-peerIDs von er "misch-entity" zur neuen "nur-channel-entity". Die "device-und-channel-entity" wird sowieso zur "nur-device-entity".
klingt evtl komplex - aus user sicher ist es, denke ich, wysiwyg. Im Coding immer ein gepfrimel, aber schon lange so.
klar soweit? Wenn nicht, gerne noch einmal nachfragen. Verstehen ist wichtig.
Gruss Martin
(http://us.cdn1.123rf.com/168nwm/lenm/lenm1209/lenm120900131/15122051-illustration-eines-dizzy-smiley-holding-ihre-leiter.jpg)
mach nur, ich werd auch DAMIT klarkommen.
ist in 3590 drin (CUL_HM und HMConfig)
wenn etwas nicht klappt, melde dich. Es soll die Lage ja verbessern. Ich denke aber du wirst es garnicht bemerken.
Gruss Martin
Hallo Martin !
Zitat von: martinp876 schrieb am Sa, 03 August 2013 11:42ok, dann sind wir soweit klar.
statusRequest noch entfernen.
Warum willst du peerIDs auch bei devices? Ist irreführend und unbrauchbar. Macht es etwas besonderes bei dir? Der Parameter gehört in erster Linie CUL_HM und ist eigentlich "intern".
Eigentilch sollte ich ihn unsichtbar machen, der User hat peerList zur Lesbarkeit
Gruss Martin
Warum hast Du den Statusrequest komplett entfernt ? Zumindest für die Heizung macht es Sinn und hat
auch funktioniert.
Gruß, Marc
sorry, hatte ich falsch verstanden. Kommt wieder rein.
Kommandos die nicht unterstützt werden muss ich immer entfernen, da so ein NACK alle nachfolgenden Kommandos im stack löscht.
Gruss Martin.
Nachtrag: kann einmal einer von euch beiden ein on-for-timer der Heizung mitloggen? Ich will ein statusbyte kontrollieren
Gruss Martin
Ich hatte den Logoutput vom statusRequest nur als Beispiel angehängt. Das Device
antwortet eigentlich auf jede Anfrage mit "NACK". Die Channels hingenen arbeiten
wunderbar. Sehr eigenartig ...
Bzgl. des powerOn war an der besagten Stelle im Code der Hash des Devices nicht
gesetzt. So funktioniert es:
874a873
> my $dhash = CUL_HM_id2Hash($src); # hash for device
927c926
< push @entities,CUL_HM_UpdtReadSingle($dhash,'powerOn',"",1);
---
> push @entities,CUL_HM_UpdtReadSingle($dhash,'powerOn',"-",1)
Eigenartig ist, dass das Reading des Devices nun sauber gesetzt wird, im Logfile
taucht aber nichts auf. Ersetzt man den push Aufruf durch eine "push @event,"powerOn: -"
aus, funktioniert beides (Update des Readings + Logeintrag), dies dann natürlich
nicht für das Device sonder für Channel 01. Ich habe auch schon ein extra "change-on-update-reading"
für das Device gesetzt. Leider keine Änderung. Ich dachte immer, dass readingsSingleUpdate
auch automatisch den Eintrag im Logfile auslösen würde ...
Gruß, Marc
# $Id: 10_CUL_HM.pm 3590 2013-08-03 11:07:14Z martinp876 $
2013-08-03 17:09:58 CUL_HM out_Regen_Heizung on
2013-08-03 17:09:58 CUL_HM out_Regen_Heizung level: 100 %
2013-08-03 17:10:18 CUL_HM out_Regen_Sensor trigger: 1:0 (to out_Regen)
2013-08-03 17:10:18 CUL_HM out_Regen powerOn:
2013-08-03 17:10:26 CUL_HM out_Regen_Sensor 0
2013-08-03 17:10:26 CUL_HM out_Regen_Sensor level: 100 %
2013-08-03 17:10:29 CUL_HM out_Regen_Heizung off
Wieso eigentlich Sensor level: 100%
Und bei powerOn kommt immer noch nix.
Hier das Log von einem on-for-timer 5
2013.08.03 17:12:54.077 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:0161C8B6 d:FF r:FFBF m:83 A258 1D919A 1DA1A9 0200
2013.08.03 17:12:54.261 1: HMLAN_Parse: HMUSB R:E1DA1A9 stat:0000 t:0161C93A d:FF r:FFBD m:83 8202 1DA1A9 1D919A 010100003A
2013.08.03 17:13:04.398 1: HMLAN_Send: HMUSB I:K
2013.08.03 17:13:04.414 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534751 d:1DAFAC O:127000 t:0161F118 IDcnt:0002
2013.08.03 17:13:10.740 1: HMLAN_Send: HMUSB S:S44BD4B93 stat: 00 t:00000000 d:01 r:44BD4B93 m:06 A011 127000 20EC04 0202C800000640
2013.08.03 17:13:10.941 1: HMLAN_Parse: HMUSB R:R44BD4B93 stat:0001 t:01620A78 d:FF r:FFAD m:06 8002 20EC04 127000 0102C84048
2013.08.03 17:13:17.760 1: HMLAN_Parse: HMUSB R:E20EC04 stat:0000 t:0162252C d:FF r:FFAB m:03 A610 20EC04 127000 06020000
Muss mich korrigieren. Ein getConfig auf Device funktioniert ohne NACK, allerdings
mit folgender Meldung:
2013-08-03_17:20:20 Regensensor RESPONSE TIMEOUT:PeerList
Da das Device anders als die Channels ja keine PeerList hat, ist das wohl normal.
Gruß, Marc
das mit dem "-" hätte ich wissen sollten. Ich denke das habe ich schon einmal überarbeitet. :-(
das mit readings und den Triggern ist so eine Sache. Solange messages verarbeitet werden funktioniert der trigger nicht. Da muss man manuell "nachtriggern".
Bei powerOn wird ein '-' kommen. Wichtig ist der Trigger und evtl der Zeitstempel
Es wird ein neues Reading geben:
timedOn:[running|off]
das sagt aus, ob der On-zustand zeitlich begrenzt ist. Kommt von Device.
Ob es auch kommt, wenn ein peer einen trigger schickt und der On-zustand "limitiert" ist habe ich noch nicht probiert.
Der Heating Channel unterstützt diese Info.
Das Reading kommt erst, wenn es einmal 'running' war.... kann man noch einmal diskutieren.
Gilt für switches und Dimmern
Ist in V 3592 (2 files, auch der Statusrequest)
ZitatEin getConfig auf Device funktioniert ohne NACK, allerdings...
wenn es keine Peers hat muss ich die Abfrage eliminieren. Kommt noch.
Gruss Martin
Nachtrag: kann ich noch ein log von getConfig haben? Channel 01 sollte schon auf peers antworten...
Hallo Martin,
die Definition von $dhash, die Du wieder rausgenommen hast, muss wohl wieder rein, sonst kommt der
alte Fehler beim powerOn zurück:
Use of uninitialized value $name in concatenation (.) or string at fhem.pl line 3275.
Use of uninitialized value $_ in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 4098.
Hier das Log vom getConfig:
2013.08.03 18:34:42 1: HMLAN_Send: HMLAN1 S:+20ECC4,00,01,
2013.08.03 18:34:42 1: HMLAN_Send: HMLAN1 S:S4507EF16 stat: 00 t:00000000 d:01 r:4507EF16 m:27 A001 F14321 20ECC4 00040000000000
2013.08.03 18:34:42 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:05375482 d:FF r:FFB8 m:27 A001 F14321 20ECC4 00040000000000
2013.08.03 18:34:42 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2E20DFDA d:FF r:FFBB m:27 A010 20ECC4 F14321 0202010AF10B430C21140618000000
2013.08.03 18:34:42 1: HMLAN_Delay: HMLAN1 20ECC4
2013.08.03 18:34:42 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:05375507 d:FF r:FFB6 m:27 A010 20ECC4 F14321 0202010AF10B430C21140618000000
2013.08.03 18:34:42 1: HMLAN_Parse: HMLAN1 R:R4507EF16 stat:0001 t:2E20DFDF d:FF r:FFBB m:27 A010 20ECC4 F14321 0202010AF10B430C21140618000000
2013.08.03 18:34:42 1: HMLAN_SdDly: HMLAN1 20ECC4
2013.08.03 18:34:42 1: HMLAN_Send: HMLAN1 S:+20ECC4,00,01,
2013.08.03 18:34:42 1: HMLAN_Send: HMLAN1 S:S4507EFDE stat: 00 t:00000000 d:01 r:4507EFDE m:28 A001 F14321 20ECC4 01040000000001
2013.08.03 18:34:42 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0537557D d:FF r:FFB8 m:27 8002 F14321 20ECC4 00
2013.08.03 18:34:42 1: HMLAN_Parse: HMLAN1 R:E1C5C64 stat:0000 t:2E20E128 d:FF r:FFC5 m:0B 8410 1C5C64 F14321 06012E0E
2013.08.03 18:34:42 1: HMLAN_Send: HMLAN1 S:S4507F118 stat: 00 t:00000000 d:01 r:4507F118 m:0B 8002 F14321 1C5C64 01012E00
2013.08.03 18:34:43 1: HMLAN_Parse: HMLAN1 R:R4507F118 stat:0002 t:00000000 d:FF r:7FFF m:0B 8002 F14321 1C5C64 01012E00
2013.08.03 18:34:43 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2E20E1E4 d:FF r:FFBC m:28 A010 20ECC4 F14321 0208002264230530060000
2013.08.03 18:34:43 1: HMLAN_Delay: HMLAN1 20ECC4
2013.08.03 18:34:43 1: HMLAN_Parse: HMUSB1 R:E1C5C64 stat:0000 t:05375656 d:FF r:FFC8 m:0B 8410 1C5C64 F14321 06012E0E
2013.08.03 18:34:43 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0537568E d:FF r:FFB7 m:28 A001 F14321 20ECC4 01040000000001
2013.08.03 18:34:43 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:053756D8 d:FF r:FFB6 m:0B 8002 F14321 1C5C64 01012E00
2013.08.03 18:34:43 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:05375710 d:FF r:FFB5 m:28 A010 20ECC4 F14321 0208002264230530060000
2013.08.03 18:34:43 1: HMLAN_Parse: HMLAN1 R:R4507EFDE stat:0001 t:2E20E1E9 d:FF r:FFBC m:28 A010 20ECC4 F14321 0208002264230530060000
2013.08.03 18:34:43 1: HMLAN_SdDly: HMLAN1 20ECC4
2013.08.03 18:34:43 1: HMLAN_Send: HMLAN1 S:S4507F23C stat: 00 t:00000000 d:01 r:4507F23C m:29 A001 F14321 20ECC4 0103
2013.08.03 18:34:43 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:05375789 d:FF r:FFB6 m:28 8002 F14321 20ECC4 00
2013.08.03 18:34:43 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:05375897 d:FF r:FFB6 m:29 A001 F14321 20ECC4 0103
2013.08.03 18:34:43 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2E20E3EB d:FF r:FFBD m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:43 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:05375917 d:FF r:FFB5 m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:43 1: HMLAN_Parse: HMLAN1 R:R4507F23C stat:0001 t:2E20E3F0 d:FF r:FFBD m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:43 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:05375995 d:FF r:FFB7 m:29 8002 F14321 20ECC4 00
2013.08.03 18:34:44 1: HMLAN_Send: HMLAN1 S:S4507F7C6 stat: 00 t:00000000 d:01 r:4507F7C6 m:29 A001 F14321 20ECC4 0103
2013.08.03 18:34:44 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:05375D2C d:FF r:FFB7 m:29 A001 F14321 20ECC4 0103
2013.08.03 18:34:44 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2E20E880 d:FF r:FFBC m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:44 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:05375DAC d:FF r:FFB5 m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:44 1: HMLAN_Parse: HMLAN1 R:R4507F7C6 stat:0001 t:2E20E885 d:FF r:FFBC m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:44 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:05375E2A d:FF r:FFB8 m:29 8002 F14321 20ECC4 00
2013.08.03 18:34:48 1: HMLAN_Send: HMLAN1 I:K
2013.08.03 18:34:48 1: HMLAN_Send: HMUSB1 I:K
2013.08.03 18:34:48 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315301 d:1C673E O:F14321 t:2E20F8AB IDcnt:0004
2013.08.03 18:34:48 1: HMLAN_Parse: HMUSB1 V:03BC sNo:JEQ0534837 d:1DB057 O:F14321 t:05376DDE IDcnt:0002
2013.08.03 18:34:48 1: HMLAN_Send: HMLAN1 S:S45080940 stat: 00 t:00000000 d:01 r:45080940 m:29 A001 F14321 20ECC4 0103
2013.08.03 18:34:49 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:05376EA4 d:FF r:FFB7 m:29 A001 F14321 20ECC4 0103
2013.08.03 18:34:49 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2E20F9F8 d:FF r:FFBC m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:49 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:05376F23 d:FF r:FFB5 m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:49 1: HMLAN_Parse: HMLAN1 R:R45080940 stat:0001 t:2E20F9FD d:FF r:FFBC m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:49 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:05376FA1 d:FF r:FFB9 m:29 8002 F14321 20ECC4 00
2013.08.03 18:34:54 1: HMLAN_Send: HMLAN1 S:S45081E4F stat: 00 t:00000000 d:01 r:45081E4F m:29 A001 F14321 20ECC4 0103
2013.08.03 18:34:54 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:053783B4 d:FF r:FFB9 m:29 A001 F14321 20ECC4 0103
2013.08.03 18:34:54 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2E210F0A d:FF r:FFB9 m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:54 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:05378434 d:FF r:FFB5 m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:54 1: HMLAN_Parse: HMLAN1 R:R45081E4F stat:0001 t:2E210F0F d:FF r:FFB9 m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:54 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:053784B2 d:FF r:FFB8 m:29 8002 F14321 20ECC4 00
2013.08.03 18:34:59 1: HMLAN_Send: HMLAN1 S:S45083393 stat: 00 t:00000000 d:01 r:45083393 m:29 A001 F14321 20ECC4 0103
2013.08.03 18:34:59 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:053798F7 d:FF r:FFB8 m:29 A001 F14321 20ECC4 0103
2013.08.03 18:34:59 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2E21244E d:FF r:FFBA m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:34:59 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:05379977 d:FF r:FFB5 m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:35:00 1: HMLAN_Parse: HMLAN1 R:R45083393 stat:0001 t:2E212453 d:FF r:FFBA m:29 A010 20ECC4 F14321 01000000
2013.08.03 18:35:00 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:053799F6 d:FF r:FFBA m:29 8002 F14321 20ECC4 00
2013.08.03 18:35:13 1: HMLAN_Send: HMLAN1 I:K
2013.08.03 18:35:13 1: HMLAN_Send: HMUSB1 I:K
2013.08.03 18:35:13 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0315301 d:1C673E O:F14321 t:2E215A79 IDcnt:0004
2013.08.03 18:35:13 1: HMLAN_Parse: HMUSB1 V:03BC sNo:JEQ0534837 d:1DB057 O:F14321 t:0537CFBF IDcnt:0002
Gruß, Marc
2013-08-03 19:28:01 CUL_HM out_Regen_Heizung timedOn: off
2013-08-03 19:28:01 CUL_HM out_Regen_Heizung on
2013-08-03 19:28:01 CUL_HM out_Regen_Heizung level: 100 %
2013-08-03 19:28:22 CUL_HM out_Regen_Sensor trigger: 1:0 (to out_Regen)
2013-08-03 19:28:22 CUL_HM out_Regen powerOn: -
2013-08-03 19:28:30 CUL_HM out_Regen_Sensor timedOn: off
2013-08-03 19:28:30 CUL_HM out_Regen_Sensor 0
2013-08-03 19:28:30 CUL_HM out_Regen_Sensor level: 100 %
2013-08-03 19:28:33 CUL_HM out_Regen_Heizung timedOn: off
2013-08-03 19:28:33 CUL_HM out_Regen_Heizung off
2013-08-03 19:28:33 CUL_HM out_Regen_Heizung level: 0 %
Was sich mir überhaupt noch nicht erschließt, ist die (für mich) völlig sinnlose 100% Angabe beim Sensor.
Hallo,
Level wird von "toggle" gebraucht - mal sehen, vielleicht werde ich es aendern. On ist bei HM für alle schalter immer 100%. Es gibt dann eben keine Zwischenwerte.
@marc: der peerRequest hat ein 'neue' terminierung - nicht ganz konform. Kannst du einmal einen Peer einrichten und dann noch einmal einen getConfig machen?
Welchen dHash meinst du jetzt? bei powerOn ist es doch drin. Wenn es dort ist werde ich es einmal simulieren müssen.
Gruss Martin
Hallo Martin !
Anbei die Logs vom getConfig mit einem eingerichteten Peer:
2013.08.03 22:16:56 1: HMLAN_Send: HMLAN1 S:+20ECC4,00,01,
2013.08.03 22:16:56 1: HMLAN_Send: HMLAN1 S:S45D365CC stat: 00 t:00000000 d:01 r:45D365CC m:14 A001 F14321 20ECC4 01011234560100
2013.08.03 22:16:56 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602C95B d:FF r:FFB8 m:14 A001 F14321 20ECC4 01011234560100
2013.08.03 22:16:56 1: HMLAN_Parse: HMLAN1 R:R45D365CC stat:0001 t:2EEC5CC8 d:FF r:FFC7 m:14 8002 20ECC4 F14321 00
2013.08.03 22:16:56 1: HMLAN_Send: HMLAN1 S:+20ECC4,00,01,
2013.08.03 22:16:56 1: HMLAN_Send: HMLAN1 S:S45D3667A stat: 00 t:00000000 d:01 r:45D3667A m:15 A001 F14321 20ECC4 00040000000000
2013.08.03 22:16:56 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:0602C9D8 d:FF r:FFB5 m:14 8002 20ECC4 F14321 00
2013.08.03 22:16:56 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602CAEF d:FF r:FFB9 m:15 A001 F14321 20ECC4 00040000000000
2013.08.03 22:16:57 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2EEC5E5F d:FF r:FFC7 m:15 A010 20ECC4 F14321 0202010AF10B430C21140618000000
2013.08.03 22:16:57 1: HMLAN_Delay: HMLAN1 20ECC4
2013.08.03 22:16:57 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:0602CB74 d:FF r:FFB6 m:15 A010 20ECC4 F14321 0202010AF10B430C21140618000000
2013.08.03 22:16:57 1: HMLAN_Parse: HMLAN1 R:R45D3667A stat:0001 t:2EEC5E64 d:FF r:FFC7 m:15 A010 20ECC4 F14321 0202010AF10B430C21140618000000
2013.08.03 22:16:57 1: HMLAN_SdDly: HMLAN1 20ECC4
2013.08.03 22:16:57 1: HMLAN_Send: HMLAN1 S:+20ECC4,00,01,
2013.08.03 22:16:57 1: HMLAN_Send: HMLAN1 S:S45D36829 stat: 00 t:00000000 d:01 r:45D36829 m:16 A001 F14321 20ECC4 01040000000001
2013.08.03 22:16:57 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602CBE9 d:FF r:FFB7 m:15 8002 F14321 20ECC4 00
2013.08.03 22:16:57 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602CCFC d:FF r:FFBA m:16 A001 F14321 20ECC4 01040000000001
2013.08.03 22:16:57 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2EEC6068 d:FF r:FFC8 m:16 A010 20ECC4 F14321 0208002264230530060000
2013.08.03 22:16:57 1: HMLAN_Delay: HMLAN1 20ECC4
2013.08.03 22:16:57 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:0602CD7E d:FF r:FFB5 m:16 A010 20ECC4 F14321 0208002264230530060000
2013.08.03 22:16:57 1: HMLAN_Parse: HMLAN1 R:R45D36829 stat:0001 t:2EEC606D d:FF r:FFC8 m:16 A010 20ECC4 F14321 0208002264230530060000
2013.08.03 22:16:57 1: HMLAN_SdDly: HMLAN1 20ECC4
2013.08.03 22:16:57 1: HMLAN_Send: HMLAN1 S:S45D36A29 stat: 00 t:00000000 d:01 r:45D36A29 m:17 A001 F14321 20ECC4 0103
2013.08.03 22:16:57 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602CDF7 d:FF r:FFB7 m:16 8002 F14321 20ECC4 00
2013.08.03 22:16:57 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602CF06 d:FF r:FFB8 m:17 A001 F14321 20ECC4 0103
2013.08.03 22:16:58 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2EEC6273 d:FF r:FFC6 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:16:58 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:0602CF89 d:FF r:FFB7 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:16:58 1: HMLAN_Parse: HMLAN1 R:R45D36A29 stat:0001 t:2EEC6278 d:FF r:FFC6 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:16:58 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602D005 d:FF r:FFB7 m:17 8002 F14321 20ECC4 00
2013.08.03 22:16:59 1: HMLAN_Send: HMLAN1 S:S45D3701B stat: 00 t:00000000 d:01 r:45D3701B m:17 A001 F14321 20ECC4 0103
2013.08.03 22:16:59 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602D3A4 d:FF r:FFB8 m:17 A001 F14321 20ECC4 0103
2013.08.03 22:16:59 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2EEC6711 d:FF r:FFC6 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:16:59 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:0602D428 d:FF r:FFB7 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:16:59 1: HMLAN_Parse: HMLAN1 R:R45D3701B stat:0001 t:2EEC6716 d:FF r:FFC6 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:16:59 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602D4A2 d:FF r:FFB9 m:17 8002 F14321 20ECC4 00
2013.08.03 22:17:01 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2EEC70D4 d:FF r:FFC6 m:04 A441 20ECC4 123456 010100
2013.08.03 22:17:01 1: HMLAN_Send: HMUSB1 S:S45D37A89 stat: 00 t:00000000 d:01 r:45D37A89 m:04 8002 123456 20ECC4 00
2013.08.03 22:17:01 1: HMLAN_Parse: HMLAN1 R:E123456 stat:0000 t:2EEC7102 d:FF r:FFBA m:04 8002 123456 20ECC4 00
2013.08.03 22:17:01 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:0602DDE8 d:FF r:FFB5 m:04 A441 20ECC4 123456 010100
2013.08.03 22:17:01 1: HMLAN_Parse: HMUSB1 R:R45D37A89 stat:0002 t:00000000 d:FF r:7FFF m:04 8002 123456 20ECC4 00
2013.08.03 22:17:01 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:0602DE2B d:FF r:FFB5 m:05 A610 20ECC4 F14321 06010000
2013.08.03 22:17:02 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2EEC7320 d:FF r:FFC6 m:05 A610 20ECC4 F14321 06010000
2013.08.03 22:17:02 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:0602E034 d:FF r:FFB6 m:05 A610 20ECC4 F14321 06010000
2013.08.03 22:17:02 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602E0AD d:FF r:FFB8 m:05 8002 F14321 20ECC4 00
2013.08.03 22:17:03 1: HMLAN_Send: HMLAN1 S:S45D38098 stat: 00 t:00000000 d:01 r:45D38098 m:17 A001 F14321 20ECC4 0103
2013.08.03 22:17:03 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602E423 d:FF r:FFB7 m:17 A001 F14321 20ECC4 0103
2013.08.03 22:17:03 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2EEC7792 d:FF r:FFC7 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:17:03 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:0602E4A5 d:FF r:FFB5 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:17:03 1: HMLAN_Parse: HMLAN1 R:R45D38098 stat:0001 t:2EEC7797 d:FF r:FFC7 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:17:03 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602E521 d:FF r:FFB9 m:17 8002 F14321 20ECC4 00
2013.08.03 22:17:04 1: HMLAN_Send: HMLAN1 S:S45D38533 stat: 00 t:00000000 d:01 r:45D38533 m:17 A001 F14321 20ECC4 0103
2013.08.03 22:17:04 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2EEC7C2C d:FF r:FFC7 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:17:04 1: HMLAN_Parse: HMLAN1 R:R45D38533 stat:0001 t:2EEC7C31 d:FF r:FFC7 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:17:09 1: HMLAN_Send: HMLAN1 S:S45D39843 stat: 00 t:00000000 d:01 r:45D39843 m:17 A001 F14321 20ECC4 0103
2013.08.03 22:17:09 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602FBCD d:FF r:FFB6 m:17 A001 F14321 20ECC4 0103
2013.08.03 22:17:09 1: HMLAN_Parse: HMLAN1 R:E20ECC4 stat:0000 t:2EEC8F3D d:FF r:FFC7 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:17:09 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:0602FC4F d:FF r:FFB4 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:17:09 1: HMLAN_Parse: HMLAN1 R:R45D39843 stat:0001 t:2EEC8F42 d:FF r:FFC7 m:17 A010 20ECC4 F14321 0112345601000000
2013.08.03 22:17:09 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:0602FCCB d:FF r:FFB7 m:17 8002 F14321 20ECC4 00
2013.08.03 22:17:14 1: HMLAN_Send: HMLAN1 S:+20ECC4,00,01,
2013.08.03 22:17:14 1: HMLAN_Send: HMLAN1 S:S45D3AB5F stat: 00 t:00000000 d:01 r:45D3AB5F m:18 A011 F14321 20ECC4 0202000000
2013.08.03 22:17:14 1: HMLAN_Parse: HMUSB1 R:EF14321 stat:0000 t:06030EED d:FF r:FFB8 m:18 A011 F14321 20ECC4 0202000000
2013.08.03 22:17:14 1: HMLAN_Parse: HMLAN1 R:R45D3AB5F stat:0001 t:2EECA25E d:FF r:FFC6 m:18 8002 20ECC4 F14321 0102000033
2013.08.03 22:17:14 1: HMLAN_Parse: HMUSB1 R:E20ECC4 stat:0000 t:06030F6B d:FF r:FFB5 m:18 8002 20ECC4 F14321 0102000033
2013.08.03 22:17:17 1: HMLAN_Send: HMLAN1 I:K
2013.08.03 22:17:17 1: HMLAN_Send: HMUSB1 I:K
Der Sensor schickt dem virtuellen Aktor zwar Trigger und diese kommen auch an, die Peerlist bleibt aber auch nach dem
getConfig leer:
fhem> list Regensensor_Status
Internals:
DEF 20ECC401
EVENTS 3
NAME Regensensor_Status
NR 132
STATE dry
TYPE CUL_HM
chanNo 01
device Regensensor
Readings:
2013-08-03 22:16:57 R-eventFilterTime 0.5 s
2013-08-03 22:16:57 R-transmitTryMax 6
2013-08-03 17:12:15 Regensensor -
2013-08-03 22:17:01 level 100 %
2013-08-03 16:30:42 powerOn -
2013-08-03 22:17:01 state dry
2013-08-03 22:17:01 timedOn off
2013-08-03 22:17:01 trigger 1:dry (to virtual_aktor)
Regl_01::
VAL
Reaginds:
Peerlist:
VAL
Helper:
getCfgList all
getCfgListNo 4
Role:
chn 1
Shadowreg:
Attributes:
expert 1
model HM-Sen-RD-O
peerIDs
room Aussen
Der virtuelle Aktor kennt den Channel jedoch:
fhem> list virtual_aktor
Internals:
CFGFN
CHANGED
DEF 123456
EVENTS 1
HMLAN1_MSGCNT 1
HMLAN1_RAWMSG E123456,0000,2EEC7102,FF,FFBA,04800212345620ECC400
HMLAN1_RSSI -70
HMLAN1_TIME 2013-08-03 22:17:01
IODev HMUSB1
LASTInputDev HMLAN1
MSGCNT 1
NAME virtual_aktor
NR 1121
STATE ???
TYPE CUL_HM
lastMsg No:04 - t:02 s:123456 d:20ECC4 00
peerList Regensensor_Status,
protLastRcv 2013-08-03 22:17:01
protState CMDs_done
rssi_at_HMLAN1 avg:-70 min:-70 max:-70 lst:-70 cnt:1
Readings:
2013-08-03 22:17:01 CommandAccepted yes
2013-08-03 22:15:29 peerList Regensensor_Status,
Helper:
rxType 1
Respwait:
Role:
chn 1
dev 1
Rssi:
At_hmlan1:
avg -70
cnt 1
lst -70
max -70
min -70
Attributes:
expert 2_full
model virtual_1
peerIDs 20ECC401,
subType virtual
Innerhalb des elsif Blocks scheint $dhash unbekannt zu sein, Du setzt nur den Hash für die Heizung. Ich
setzte daher innerhalb dieses Blocks $dhash noch einmal explizit, und scheint es zu funktionieren. Zumindest
wird das Reading "powerOn" gesetzt und es gibt keine Fehlermeldung mehr:
elsif($st eq "sensRain") {###################################################
my $hHash = CUL_HM_id2Hash($src."02");# hash for heating
my $dhash = CUL_HM_id2Hash($src); # hash for device
my $pon = 0;# power on if mNo == 0 and heating status plus second msg
# status or trigger from rain channel
In Sachen Status Request habe ich wohl Mist erzählt. Wenn ich auf Ebene des Channels einen
StatusRequest absetze, quittiert das Devices das trotzdem mit "NACK". Wenn also nicht
jemand noch etwas gegenteiliges behauptet, kann der StatusRequest wohl wirklich komplett
raus :-(
Gruß, Marc
irgendwie kommen aktuell noch ganz andere HM-Komponenten durcheinander, wobei ich noch nicht weiß, ob das mit den Basteleien hier aus dem Thread zusammenhängt.
Alle Fenster-Drehgriffkontakte stehen plötzlich nur noch auf Missing Ack - obwohl sie beim Betätigen eine grüne Bestätigung melden.
ok, das mit dem dHash habe ich verstanden, blöder Fehler, lag sicher an der Hitze.
Auch die Nachlässigkeit des RainSens die peerTermination um 2Byte zu kürzen ist berücksichtigt (alle sind gleich nureinige sind gleicher). Bitte testen (mit und/oder ohne peer).
Level habe ich ubsichtbar gesetzt - du musst erst die Readings löschen um den Level zu entfernen (set clear readings)
Den StatusRequest des Heat-channels habe ich auch entfernt - wenn ihr sicher seid.
@betateilchen - schicke einmal ein log, wenn es heute immer noch ein Problem ist.
Version 3594
Gruss Martin
Hallo Martin,
sorry das ich nicht mehr mittesten konnte. Hab ein ziemlich blödes Wochenende hinter mir.
Hab gerade mal etwas Zeit gefunden und getestet ob ich ein Funkmodul mit Arduino ans laufen bekomme...
Kannst du mit den Strings was anfangen?
start AskSin sketch
SPI_init done
cc1100_init:1234.......................5..........6
cc1100_init done
-> 11 bytes
06 A2 40 1F A6 5C 63 19 63 01 69
-> 13 bytes
06 80 02 63 19 63 1F A6 5C 01 01 C8 00
-> 10 bytes
07 80 02 63 19 63 1F A6 5C 00
-> 11 bytes
08 A2 40 1F A6 5C 63 19 63 05 21
-> 13 bytes
08 80 02 63 19 63 1F A6 5C 01 01 C8 00
-> 10 bytes
09 80 02 63 19 63 1F A6 5C 00
-> 11 bytes
0A A2 40 1F A6 5C 63 19 63 04 26
-> 13 bytes
0A 80 02 63 19 63 1F A6 5C 01 01 00 00
-> 11 bytes
0C A2 40 1F A6 5C 63 19 63 02 3A
Die kommen aus dem Homematic 6 Tasten Funkwandsender...
Das sind abgefangene Funkdaten vom Regensensor
Nass - Trocken
-> 12 bytes
2E A4 41 20 EC 71 12 34 56 01 15 C8
-> 13 bytes
2F A6 10 20 EC 71 63 19 63 06 01 C8 00
-> 12 bytes
30 A4 41 20 EC 71 12 34 56 01 16 00
-> 13 bytes
31 A6 10 20 EC 71 63 19 63 06 01 00 00
-> 12 bytes
32 A4 41 20 EC 71 12 34 56 01 17 C8
-> 13 bytes
33 A6 10 20 EC 71 63 19 63 06 01 C8 00
-> 12 bytes
34 A4 41 20 EC 71 12 34 56 01 18 00
-> 13 bytes
35 A6 10 20 EC 71 63 19 63 06 01 00 00
Sag mir bitte ob ich auf dem richtigen Weg bin bzgl. des Empfangs.
Ich würde dann im Forum unter Homematic ein neues Post aufmachen und die Sourcen teilen, so
dass auch Andere hier ein wenig Mitarbeiten können.
Viele Grüße
Horst
Hallo Horst
Sieht gut aus. Ich lese
Wandsender schickt trigger von Taste 1/5/4/2 in der Reihenfolge
631963 ACKed mit 1->on,5->on,4->of,2->keine Reaktion
Regensensor meldet
regen/dry/regen/dry
alles auch mit trigger an 123456,welcher nicht antwortet
Gruss Martin
Hallo Martin,
mir sind noch zwei Dinge zu dem Regensensor aufgefallen:
1. es scheint kein alive zu geben, im ActionDetectorLog taucht er nicht auf
2. mir fehlt ein Reading "last rain" das den Inhalt eines timestamps enthält, wann der letzte Wechsel von "rain" auf "dry" stattfindet. Ein Trigger auf "dry" alleine erfüllt den Zweck nicht, weil ein dry auch dann kommt, wenn der Sensor mit Spannung versorgt wird.
Viele Grüße
Udo
Zitates scheint kein alive zu geben, im ActionDetectorLog taucht er nicht auf
korrekt. Es ist keine Zyklische message angegeben , an der ich dies festmachen kann.
Du kannst dies wie bei jeden Device selbst addieren:
attr <rainSensDev> actCycle <hh:mm>
also
attr <rainSensDev> actCycle 00:05
dann wird alle 5 min eine message erwartet und du wirst ihn im ActionDetector sehen. Siehe Auch Commandref.
Schickt der reinsensor regelmässig messages
Zitatmir fehlt ein Reading "last rain"
ok, macht sinn. Steht zwar auch im Logfile und du könntest es als Grafik ausgeben, aber es ist evtl wichtig genug um im frontend zu erscheinen.
Probier Version 3612
Gruss Martin
Hallo Martin,
das lastRain kann ich aus dem Logfile nicht eindeutig ableiten - wie oben beschrieben, schickt der Sensor ja nach Anlegen der Betriebsspannung ebenfalls ein "dry" wenn es nicht regnet. Das heißt aber nicht, dass es eine Sekunde VOR diesem Einschaltzeitpunkt geregnet haben muss. Es ist also wichtig, nicht den Zustand selbst, sondern den Zustandswechsel auszuwerten.
Ich werde die neue Version testen, es sieht heute hier nach Regen aus.
Übrigens war mein Sensot jetzt mehrere Tage komplett ausgefallen, was ich nicht bemerkt hatte - und so kam ich auf das fehlende alive. Auch diesen Tipp von Dir werde ich testen, wobei ich noch nicht verstenden habe, welche Message dann vom Sensor kommen soll.
und wenn es nicht regnet hast du sicher eine Gieskanne ;-)
lastRain kommt erst, wenn es trocken wird. Solange es regnet hast du also current und last rain
funktioniert nicht.
2013-08-08_11:53:49 out_Regen_Sensor trigger: 1:0 (to out_Regen)
2013-08-08_11:53:55 out_Regen_Sensor timedOn: off
2013-08-08_11:53:55 out_Regen_Sensor 0
2013-08-08_11:56:39 out_Regen_Sensor trigger: 2:25 (to out_Regen)
2013-08-08_11:56:47 out_Regen_Sensor timedOn: off
2013-08-08_11:56:47 out_Regen_Sensor 25
2013-08-08_11:57:22 out_Regen_Sensor trigger: 3:0 (to out_Regen)
2013-08-08_11:57:30 out_Regen_Sensor timedOn: off
2013-08-08_11:57:30 out_Regen_Sensor 0
Internals:
DEF 20EC0401
EVENTS 6
NAME out_Regen_Sensor
NR 340
STATE 0
TYPE CUL_HM
chanNo 01
device out_Regen
Readings:
2013-08-02 14:48:12 R-eventFilterTime dry.5
2013-08-02 14:48:12 R-transmitTryMax 6
2013-08-02 14:48:12 RegL_01: 08:00 22:64 23:05 30:06 00:00
2013-08-03 19:28:30 level 100 %
2013-08-08 11:57:30 state dry
2013-08-08 11:57:30 timedOn off
2013-08-08 11:57:22 trigger 3:dry (to out_Regen)
Helper:
Role:
chn
Eigentlich muss das lastEain doch einfach bei jedem ungeraden Trigger gesetzt werden, der größer als 1 ist.
(und: nein, das Reading existiert auch im Device nicht)
mal schaun, sehen den Fehler noch nicht.
Nein, mit dem Trigger hat es nichts zu tun, das ist eine andere Baustelle.
Der "level" ist veraltet, den gibt es so nicht mehr. Falls du es loswerden willst kannst du alle Readings löschen und neu lesen:
set out_Regen clear readings
set out_Regen getConfig
Was mich wundert ist
Zitatout_Regen_Sensor 25
Das sollte es so nicht geben.
Ich gehe davon aus, dass der Channel das Attribut model=HM-Sen-RD-O hat?
Gruss Martin
Zitat von: martinp876 schrieb am Do, 08 August 2013 13:34Was mich wundert ist
Zitatout_Regen_Sensor 25
Das sollte es so nicht geben.
wundere Dich nicht weiter...
Attributes:
eventMap rain:25 dry:0
Ich brauche das so (numerisch) zum Plotten.
hm - ich frage auf "rain" ab.
kannst du das Mapping einmal entfernen - testhalber?
Ich werde auch einmal etwas spielen.
klar kann ich das...
2013-08-08 15:15:11 CUL_HM out_Regen_Heizung trig_out_Regen_Sensor: rain
2013-08-08 15:15:11 CUL_HM out_Regen_Heizung trigLast: out_Regen_Sensor:rain
2013-08-08 15:15:11 CUL_HM out_Regen_Sensor trigger: 4:rain (to out_Regen)
2013-08-08 15:15:19 CUL_HM out_Regen_Sensor timedOn: off
2013-08-08 15:15:19 CUL_HM out_Regen_Sensor rain
2013-08-08 15:15:22 CUL_HM out_Regen_Heizung timedOn: off
2013-08-08 15:15:22 CUL_HM out_Regen_Heizung on
2013-08-08 15:15:26 CUL_HM out_Regen_Heizung trig_out_Regen_Sensor: dry
2013-08-08 15:15:26 CUL_HM out_Regen_Heizung trigLast: out_Regen_Sensor:dry
2013-08-08 15:15:26 CUL_HM out_Regen_Sensor trigger: 5:dry (to out_Regen)
2013-08-08 15:15:34 CUL_HM out_Regen_Sensor timedOn: off
2013-08-08 15:15:34 CUL_HM out_Regen_Sensor dry
2013-08-08 15:15:35 CUL_HM out_Regen_Heizung timedOn: off
2013-08-08 15:15:35 CUL_HM out_Regen_Heizung off
aber ein neues Reading habe ich trotzdem nirgends.
Ich habe mir jetzt eine Funktion gebastelt, die per notify jeden trigger des Regensensors auf "ungerade und größer als 1" prüft.
das Reading löst keinen Trigger/event aus. Du musst in "list" oder dem Web interface nachsehen.
Gruss Martin
ich bin die ganze Zeit im Web Interface...
Readings:
2013-08-08 13:53:38 R-eventFilterTime dry.5
2013-08-08 13:53:39 R-self02-expectAES off
2013-08-08 13:53:39 R-self02-peerNeedsBurst off
2013-08-08 13:53:38 R-transmitTryMax 6
2013-08-08 13:53:38 RegL_01: 08:00 22:64 23:05 30:06 00:00
2013-08-08 13:53:39 RegL_04:self02 01:00 00:00
2013-08-08 15:19:28 peerList self02,
2013-08-08 15:15:34 state dry
2013-08-08 15:15:34 timedOn off
2013-08-08 15:15:26 trigger 5:dry (to out_Regen)
die 15:15:xx Readings sind die aus dem obigen Log
ok, geht nichts über den Test. Leider kann man "state" nicht wie ein normales Reading auslesen.... mein Fehlern.
Habe es umgebaut. Probier einmal
Gruss Martin
Zitat von: martinp876 schrieb am Do, 08 August 2013 16:50Habe es umgebaut.
Readings:
2013-08-08 13:53:38 R-eventFilterTime dry.5
2013-08-08 13:53:39 R-self02-expectAES off
2013-08-08 13:53:39 R-self02-peerNeedsBurst off
2013-08-08 13:53:38 R-transmitTryMax 6
2013-08-08 13:53:38 RegL_01: 08:00 22:64 23:05 30:06 00:00
2013-08-08 13:53:39 RegL_04:self02 01:00 00:00
2013-08-08 17:16:38 lastRain 2013-08-08 17:16:21
2013-08-08 15:19:28 peerList self02,
2013-08-08 17:16:38 state dry
2013-08-08 17:16:38 timedOn off
2013-08-08 17:16:30 trigger 7:dry (to out_Regen)
sieht erstmal gut aus.
ok - checke ich ein.
wieder einmal die "state" Sonderbehandlung... na ja
V3620
Gruss Martin
so klappts auch mit der Spannungsversorgung für den Sensor, wenn es keine Außensteckdose gibt:
(http://up.picr.de/15453498jg.jpg)
Komplette Beschreibung (http://forum.fhem.de/index.php?topic=14204.0)
Moin !
Tun Eure Regensensoren noch ? Meiner scheint nach rund zwei Wochen Dauerbetrieb den
Geist aufgegeben zu haben. Wenn man ihn neu startet (Spannungsversorgung ab und wieder
anklemmen) meldet er zwar noch seinen Zustand (an die Zentrale, nicht als
Broadcast, d.h. das Pairing scheint noch ok zu sein), Anfragen der Zentrale werden
aber grundsätzlich ignoriert, es gibt keinerlei Antwort vom Sensor (mit hmsniff
gsniffert). Hatte schon einmal jemand ein ähnliches Problem ? Muss ich wohl
austauschen lassen ...
Gruß, Marc
Ich hatte am Anfang ein Problem mit der Spannungsversorgung. Versorgt aus einem 13,8V/30A Netzteil meiner Funktechnik lief der Sensor nicht zuverlässig. Seit ich ihm ein eigenes 7,5V/1A Steckernetzteil spendiert habe, gab es keine Probleme mehr. Den letzten Regen hat der Sensor am Montagabend gemeldet, seitdem bin ich nicht zu Hause gewesen, aber ich denke, er wird noch funktionieren, wenn ich morgen zurück bin.
Mein Sensor zu Hause meldet gerade Regen - er lebt also noch :)
Hallo Betateilchen,
was genau meinst Du mit "nicht zuverlässig". Bei mir hängt er an einer 12V Stromversorgung und lief
rund drei Wochen lang klaglos (davon 1 Woche im Testbetrieb drinnen, und zwei Wochen draussen). Seit
gestern quittiert er plötzlich kein "on/off" der Heizung mehr. Werde wohl mal auf die Leiter steigen,
und neu pairen (auch wenn die "dry" Meldung beim Start sauber an die Zentrale geht) ...
Gruß, Marc
Zitat von: marc2 schrieb am Sa, 24 August 2013 22:59was genau meinst Du mit "nicht zuverlässig".
Nach einer undefinierten Zeit war er einfach tot, obwohl noch die Betriebsspannung anlag. Erst ein Trennen und Wiedereinschalten sorgte dafür, dass der Sensor wieder für eine nicht vorhersagbare Zeit arbeitete. Seit dem Einsatz des 7,5V Netzteils trat dieses Verhalten nie wieder auf. Ich denke, der sehr weit gefaßte Versorgungsspannungsbereich in den technischen Daten ist sehr optimistisch gewählt. Zumal der gesamte Sensor nur mit 3,3V arbeitet.
Irgendwie sieht das komisch aus...
(siehe Anhang / see attachement)
2013-08-rain wird so nicht geschrieben. hast du etwas laufen, das ein substitude macht? Welche attribute sind aktiv?
Das Thema hatten wir schonmal. Ich habe eine Eventmap, die "rain" auf 25 und "dry" auf 0 mappt, weil ich das fürs Plotten brauche.
Warum dadurch aber ein Timestamp umgemappt wird (und dann auch noch falschrum), ist mir völlig unklar.
Bei "R-eventFilterTime" passiert übrigens genau das gleiche. Anstatt "0.5" steht da "dry.5" weil die 0 umgemappt wird.
Internals:
DEF 20EC0401
NAME out_Regen_Sensor
NR 338
STATE 0
TYPE CUL_HM
chanNo 01
device out_Regen
peerList self02,
Readings:
2013-08-08 13:53:38 R-eventFilterTime dry.5
2013-08-08 13:53:39 R-self02-expectAES off
2013-08-08 13:53:39 R-self02-peerNeedsBurst off
2013-08-08 13:53:38 R-transmitTryMax 6
2013-08-08 13:53:38 RegL_01: 08:00 22:64 23:05 30:06 00:00
2013-08-08 13:53:39 RegL_04:self02 01:00 00:00
2013-08-25 22:21:20 lastRain 2013-08-rain
2013-08-26 21:58:07 peerList self02,
2013-08-25 22:21:20 state dry
2013-08-25 22:21:20 timedOn off
2013-08-25 22:21:12 trigger 181:dry (to out_Regen)
Helper:
Role:
chn 1
Attributes:
eventMap rain:25 dry:0
expert 2_full
group Balkon Wetter
model HM-Sen-RD-O
peerIDs 00000000,20EC0402,
room 20_Wetter,17_Balkon
hm, eventMap ist nicht wirklich meine Baustelle.
Habe einmal reingesehen, was es so macht
a) EventMap wirkt auf ALLE Readings
b) eventMap sucht "ganze wörter im string"
c) das Ende wird nach einem Treffer abgeschnitten (sehe ich als Bug, kann aber absicht sein)
du willst alle "25" mit "rain" ersetzen.
in lastRain steht '2013-08-25 10:03:25' - oder so
'-',':' und ' ' sind offizielle "Wortbegrenzer". Somit werden folgende mögliche Worte gefunden
2013,08,25,10,03,25.
Beim ersten '25' hat eventMap einenTreffer und ersetzt den String.
Nicht ganz klar, warum das Ende abgeschnitten wird.
Nicht viel, was ich machen kann.
- EventMap kann ich nicht für diesen Fall umbauen
- ersetzen von Zahlen ist gefährlich in EventMap
- eventMap erlaubt einen modifier - dieser scheint noch nicht definiert
- lastRain ist ein Zeitstempel in normalem Format.Einen Umbau des Formats sehe ich daher nicht als Sinnvoll
Wenn du zahlen mit eventmap weiterhin ersetzen willst musst du dir etwas einfallen lassen.
Wenn du einen Vorschlag hast, was der rain sensor melden sollte, lass hören
Gruss Martin
Zitat von: martinp876 schrieb am Di, 27 August 2013 09:03Wenn du zahlen mit eventmap weiterhin ersetzen willst
Genau
das will ich doch überhaupt nicht!
Ich will Text durch Zahlen ersetzen, nicht andersrum.
Genauer: "rain" wird zu 25 und "dry" wird zu 0.
Ich denke auch, dass die Fehlerursache in der Abhandlung der eventMap liegt und das nicht Deine Baustelle ist. Aber es tritt in Deinem Modul auf ;)
nun, eventMap reagiert - und muss dies auch - in beide Richtungen.
Es sollte eigentlich behoben sein, wenn du statt 25 einfach 000025 schreibst. Deine Auswertung sollte es immer noch als Zahl erkennen, der eventMap string-parser aber die 000025 nicht finden.
Alternativen sind auch
25.00
Gruss Martin
ich werd mich mal bei Rudi über das Verhalten von eventMap (das Fehlverhalten war mir schon an anderen Stellen begegnet, wo es aber nicht so schlimme Auswirkungen hatte) beschweren *g*
(siehe Anhang / see attachement)
Was ist eigentlich der Unterschied zwischen eventFilterTime und eventFilterTimeB
eventFilterTime ist nicht mehr teil vom Regensensor. Das Reading ist ja auch schon 3 Wochen alt.
Register haben unterschiedliche Namen auch wenn ich nur den Wertebereich aendern muss. "b" hat einen minwert von 5, der ohne "b" kann auch "0" annehmen.
wenn du ein clear readings machst und neu liest wird "" verschwunden sein.
das "dry" ist sicherwieder dein EventMap
Zitat von: betateilchen schrieb am Di, 27 August 2013 10:10ich werd mich mal bei Rudi über das Verhalten von eventMap (das Fehlverhalten war mir schon an anderen Stellen begegnet, wo es aber nicht so schlimme Auswirkungen hatte) beschweren *g*
Hallo Martin,
kannst Du uns diesbezüglich mal bitte hier
Link weiterhelfen? Irgendwie drehen wir uns im Kreis.
Viele Grüße
Udo
Moin zusammen !
Nach langer Zeit - verhindert durch Arbeit und später Urlaub - habe ich heute die Leiter
rausgeholt, um zu schauen, warum der Sensor nach zwei Wochen den Betrieb eingestellt hatte.
Ohne das Gehäuse nur geöffnet zu haben war aufgrund des Schwitzwassers unter dem Sichtfenster
der LEDs klar, was hier der Grund war. Nach dem Öffnen des Gehäuses bot sich ein desaströser
Anblick. Über die vergangenen (nunmehr) 6 Wochen seit der Installation war soviel Wasser
in das Gehäuse eingedrungen, dass der untere Bereich der Platine nahezu unter Wasser stand
und beschädigt war (Kupferschicht teilweise bereits abgelöst). Ähnliche Erfahrungen kann
man auch im Homematic Forum nachlesen. Ursache ist wohl eine Undichtigkeit der Sensoroberfläche,
die die erste Version des Sensors betrifft.
Gruß, Marc
Hallo
ich habe jetzt den Bausatz funktionsbereit und nach längerm Versuchen, geschaft zu pairen.
Jetzt habe ich nur noch das Problem, dass der State vom Regensensor immer ??? anzeigt.
Die Heizung funktioniert mitlerweile zu schalten,
wobei hier auch der State nicht von set_off auf off wechselt.
Was kann ich noch tun, um hier weiter zu kommen?
Schöne Grüße
Hannes
dann stimmt wohl das pairing noch nicht ganz.
Hallo,
danke erst mal für die Antwort :-)
Wie schon gesagt, war es überhaupt ziemlich langwierig bis ich es überhaupt soweit gebracht habe.
Erst nach dem ich die File
00_HMLAN.pm
HMConfig.pm
aus dem fhem-code-3964-trunk upgedatet habe bekam ich eine Verbindung.
Der Regensensor zeigt bei List
fhem> list Regensensor_Heizung
Internals:
DEF 20EC4F02
NAME Regensensor_Heizung
NR 236
STATE set_off
TYPE CUL_HM
chanNo 02
device Regensensor
Readings:
2013-09-26 20:30:05 CommandAccepted yes
2013-09-26 20:30:05 state set_off
Helper:
Role:
chn 1
Attributes:
expert 2_full
model HM-Sen-RD-O
peerIDs
room CUL_HM
und der Schalter
fhem> list Regensensor_Rain
Internals:
DEF 20EC4F01
NAME Regensensor_Rain
NR 235
STATE ???
TYPE CUL_HM
chanNo 01
device Regensensor
Readings:
2013-09-26 20:26:46 R-eventFilterTimeB conversion undefined - please contact admin
2013-09-26 20:26:46 R-transmitTryMax 6
2013-09-26 21:43:08 RegL_01: 08:00 22:64 23:05 30:06 00:00
Helper:
Role:
chn 1
Attributes:
model HM-Sen-RD-O
peerIDs
room CUL_HM
Das Schalten der Heizung funktioniert alledings :-)
Gruß Hannes
Hallo Hannes,
wenn Deine Heizung zwar schaltet der Status aber auf "set_off" (oder "set_on")
stehen bleibt, und zudem der State des Sensors immer auf "???" stehen bleibt,
dann kommen entweder die Messages (incl. ACKs), die der Sensor sendet, nicht an,
oder der sie werden verworfen. Letzteres kann ich mir nicht vorstellen, da FHEM
dem Sensor auch keine "set_on" oder "set_off" schicken würde. Wie sehen denn die
RSSI Werte aus ? Wie weit ist der Sensor entfernt ? Hast Du schon einmal "Trockenübungen"
in der Nähe Deines HMLAN (oder CUL) durchgeführt. Wenn die RSSI Werte ok sind, und
auch ein erneutes Pairing nichts bringt, dann wirst Du die Messages mitschneiden
und posten müssen. Anleitungen hierzu findest Du hier im Forum zu Hauf.
Gruß, Marc
Danke Marc erst mal.
Der Regensensor ist etwa 1m vom HMLan weg,
Beim testen.
Die RSSI Werte werde ich aber trotzdem anschauen,
wenn ich wieder zu Hause bin.
Auch bezüglich dem Mitschneiden werde ich mich kundig machen.
Gruss Hannes
Hallo Marc,
jetzt bin ich wieder zu Hause und habe mir den Regensensor nochmals geschnappt.
Muss dazu sagen, habe heute Vormittag auf fhem 5.5 upgedatet.
Nun habe ich das pairen nochmals versucht
und siehe da nun geht alles einwandfrei :-) :-).
Leider habe ich seit dem Update auf 5.5 das Problem,
dass die Webseite sehr langsam aktualisiert und die Reaktion auf Events stark verzögert sind.
Dazu habe ich aber einen separaten Punkt unter Fritzbox aufgemacht.
Dieser Punkt ist jedenfalls seit dem Update behoben,
ob es wirklich daran gelegen hat, kann ich jedoch nicht 100%ig sagen.
Schöne Grüße und besten Dank
Zitat von: marc2 schrieb am Mo, 30 September 2013 19:14Ursache ist wohl eine Undichtigkeit der Sensoroberfläche,
die die erste Version des Sensors betrifft.
Musstest Du bei Deinem Bausatz die Sensorfläche selbst in den Deckel kleben (wie in der Anleitung beschrieben) oder war die schon vormontiert?
Hi !
Die Sensorfläche war bereits eingeklebt ...
Gruß, Marc
Hallo
Die Sensorfläche war schon eingeklebt.
Gruss Hannes
Hallo Martin,
zwei Kleinigkeiten sind mir in den letzten Tagen aufgefallen, die zwar nicht wirklich dramatisch sind, aber interessieren würde mich der Hintergrund trotzdem.
1. Irgendwie funktioniert das Reading lastRain nicht immer richtig.
(http://up.picr.de/16174793hc.png)
Die Uhrzeit bei trigger ist korrekt, die Uhrzeit bei lastRain aber nicht.
2. Was bewirkt eigentlich das Register R-eventFilterTimeB ?
lastRain ist der Zeitpunkt des letzten Triggers "rain". Das Reading wird gesetzt wenn es wieder trocken ist, als o das letzte mal "rain" erkannt wurde.
Es hat also am 13. vor 2:42:21 zu regen begonnen - dann kamen beliebig vielen trigger. der letzte rain um 2:42:21. Um 2:43:26 kam dann "Trocken" das 'erste' mal.
Wenn es wieder regnet bleibt lastRain auf diesem Wert - bis es aufhört zu regnen.
um 9:40:07 hat der sensor einen Trigger an "out_Regen" mit 'dry' gesendet. Das oben waren status-messages, keine trigger.
ganz schlüssig ist es nicht, warum der trigger so spät kommt.
hast du mitgeloggt, wie sich 'state' verändert? Wann ist das auf 'dry' gegangen?
Event-filter-time ist dem Namen nach die minimale zeit zwischen triggern - also schneller können trigger nicht kommen. schön. wenn du es testen könntest.
Gruss Martin
Es hatte gestern um 09:40 aufgehört zu regnen.
die eventFilterTimeB (früher hieß die mal nur eventFilterTime) kann ich setzen wie ich will - da ändert sich irgendwie nix.
kannst du bei deinem setting von 30sec trigger erzeugen, die schneller kommen?
Wohlgemerkt TRIGGER - nicht status-meldungen.
kannst du es einmal 5sec regen/5sec trocken/5sec regen......
wann kommen die Trigger readings?
das B kommt daher, dass es das Register auch bei anderen Devices gibt - aber miit anderen min/max werten. Da ich aber einen eindeutigen Namen brauche habe ich ein "B" angehängt.
Beispiel von heute:
(http://up.picr.de/16180219sh.png)
es hat von 14:30 bis 15:30 Uhr geregnet.
In den Readings steht:
(http://up.picr.de/16180221ov.png)
Irgendwie sieht es aus, als würde lastRain auf den Beginn des Regens gestellt und nicht auf das Ende.
muss ich dir recht geben - und meine code besser lesen.
lastRain <startOfRain> <endOfRain>
lastRain wird ausgegeben, wenn es aufhört zu regnen.
der "wert" ist der Beginn des letzten regens, der Zeitstempel das Ende. Somit kannst du die Dauer errechnen.
während es regnet ist lastRain noch auf den "vor-regen"
Ich vermerke es so im Commandref.
evtl kannst du einen Wiki-beitrag erarbeiten?
Gruss Martin
das war aber m.E. schonmal anders, da würde ich fast drauf wetten. Sonst wäre mir das ja gar nicht aufgefallen.
nachdem ich schon länger nichts mehr hier geaendert habe...
sinn macht es m.E. man hat anfang und ende des letzten Regens - kann man noch mehr bekommen? sollte es anders sein?
jaja, man muss als Verkäufer nur gut argumentieren können 8)
draussen schüttet es wie aus Eimern und der Sensor kriegt mal wieder nix mit... *grummel*
sorry, die beiden letzten habe ich nicht...???
es wurde m.W. nichts geändert, es gibt keine anderen oder besseren Vorschläge - und die Funktion der HW ist eine andere Baustelle - vielleicht die wasserqualität des Regens?
Schon klar, dass das Nichterkennen ein Hardwareproblem ist und nicht die Software dafür verantwortlich ist.
Der Regensensor funktioniert nach dem Firmwareupdate auch nicht mehr richtig. Genauer: Der Heizungschannel liefert nur noch NACK zurück.
Neue Parameter in Firmware 1.4 des Regensensors:
(http://up.picr.de/17206705jl.jpg)
kannst du einen trace ziehen?
wie hast du eigentlich den update gemacht?
Nach den Erfahrungen mit dem RT werde ich den Regensensor heute abend mal komplett aus fhem löschen und dann neu einrichten. Vielleicht hilft das schon. Dann kann ich Dir auch einen Trace ziehen.
Update? Genau wie beim RT: über die CCU2. Es war sogar einfacher, weil dafür am Regensensor keinerlei Eingriffe (manuelles Umschalten in Update-Mode) notwendig waren. Das hat einfach out-of-the-box funktioniert. Der Sensor muss natürlich mit der CCU2 gepaired sein.
Zitat von: marc2 am 30 September 2013, 19:14:53Nach langer Zeit - verhindert durch Arbeit und später Urlaub - habe ich heute die Leiter rausgeholt, um zu schauen, warum der Sensor nach zwei Wochen den Betrieb eingestellt hatte. Ohne das Gehäuse nur geöffnet zu haben war aufgrund des Schwitzwassers unter dem Sichtfenster der LEDs klar, was hier der Grund war.
Gestern musste ich meinen Regensensor zum Behufe eines Firmwareupdates auch demontieren (geht hier glücklicherweise problemlos ohne Leiter) und öffnen. Wasser war keines drin, alles furztrocken. Glück gehabt.
Was mit aber sehr unangenehm auffiel, war die Tatsache, dass die Sensorfläche selbst schon ziemlich korrodiert aussah. Irgendwie werde ich das Gefühl nicht los, dass der Heizungsbetrieb der Sensoroberfläche nicht wirklich guttut. Ich werde den Sensor jetzt eine Weile komplett ohne Heizung betreiben und schauen, ob sich der Zustand an der Oberfläche weiter verschlimmert.
Zitat von: betateilchen am 29 Januar 2014, 21:46:49
Der Regensensor funktioniert nach dem Firmwareupdate auch nicht mehr richtig. Genauer: Der Heizungschannel liefert nur noch NACK zurück.
Ich habe jetzt den Regensensor aus fhem gelöscht und dann neu gepairt. Nun funktioniert auch die Heizung wieder.
Die Parameter im Sensor sehen jetzt übrigens auch anders aus:
(http://up.picr.de/17224372fz.jpg)
Irgendwie fehlt in fhem noch die Darstellung der Schaltschwelle für Trockenheit.
(http://up.picr.de/17224409ic.png)
Hallo Martin,
gibt es eigentich das Reading lastRain nicht mehr? Ist mir erst heute aufgefallen, dass das nicht mehr existiert.
doch, sollte noch kommen. Immer wenn ein Uebergang von Rain nach Dry kommt sollte lastRain gesetzt werden. Ein reboot darf nicht dazwischen liegen
hm... gestern abend kam das Reading jedenfalls nicht. Ich werde das heute abend nochmal testen.
Funktioniert.
Wahrscheinlich war während des Experimentierens mit dem TC-peering irgendein fhem-Neustart während des Regens dazwischengekommen.
werde einmal versuchen, den statte nach reset zu recovern - wenn die Readings ueberleben next update
Hallo,
das Thema hier ist ja schon was älter, aber mich würde es mal interessieren, ob Eure Regensensoren noch funktionieren.
Meiner hat nach sage und schreibe 1,5 Monaten den Geist aufgegeben.
Reagierte nicht mehr, da dachte ich mir muss ich doch mal nachschauen.
Nun denn. Gehäuse geöffnet und es war Wasser drin. :o
Und nicht nur Schwitzwasser, dafür war es mMn zu viel.
Obwohl ich den meiner Meinung nach korrekt mit allen mitgelieferten Dichtungen montiert habe.
Na mal schauen, was der Lieferant dazu sagt...
Meiner läuft seit der Inbetriebnahme problemlos.
"kommt leider vor das der Sensor nicht richtig verklebt ist ....."
Immerhin gibt's einen Vorabtausch des Sensors.
Ich hoffe nur, dass der neue richtig verklebt ist.
Nicht, dass es da wieder rein regnet.
Hi zusammen,
wollte gerade einen neuen Regensensor in Betrieb nehmen.
Beim pairen bekomme ich aber nur folgende Fehlermeldung im Log angezeigt:
HMLAN1: Unknown code A0D00861023FB9D0000000602C800::-61:HMLAN1, help me!
HMLAN1: Unknown code A0D01861023FB9D00000006010000::-61:HMLAN1, help me
Weiß hier jemand rat, wie ich das Gerät gepairt bekomme?
Gruß
Hans
das hat nichts mit dem pairen zu tun. ist bestimmt eine zyclische status meldung eines unbekannten devices. entweder dein pairing hat nicht geklappt, oder ein anderes unbekanntes device (nachbar?) ist am funken. mit einer virtuellen ccu kann man solche meldungen beseitigen. wurde schon häufig beschrieben.
mache rohmessages vom pairing des rd. ist die funkstrecke in ordnung? batterien voll?
Hi Frank,
vielen Dank für die schnelle Antwort.
Ein Device vom Nachbarn schließe ich aus, da die Meldung nur direkt beim Pairung-Versuch auftritt. Strom kommt aus der Steckdose.
Folgende Meldungen mit Verbose 5 erscheinen im Log:
2014.08.01 18:40:57 5: HMLAN/RAW: /E23FB9D,0000,5A050E13,FF,FFC8,00861023FB9D0000000602C800
2014.08.01 18:40:57 5: HMLAN_Parse: HMLAN1 R:E23FB9D stat:0000 t:5A050E13 d:FF r:FFC8 m:00 8610 23FB9D 000000 0602C800
2014.08.01 18:40:57 5: HMLAN1 dispatch A0D00861023FB9D0000000602C800::-56:HMLAN1
2014.08.01 18:40:57 5: Triggering HMLAN1 (1 changes)
2014.08.01 18:40:57 5: Notify loop for HMLAN1 UNKNOWNCODE A0D00861023FB9D0000000602C800::-56:HMLAN1
2014.08.01 18:40:57 4: eventTypes: HMLAN HMLAN1 UNKNOWNCODE A0D00861023FB9D0000000602C800::-56:HMLAN1 -> UNKNOWNCODE A0D00861023FB9D0000000602C800::-.*:HMLAN1
2014.08.01 18:40:57 3: HMLAN1: Unknown code A0D00861023FB9D0000000602C800::-56:HMLAN1, help me!
2014.08.01 18:40:58 5: HMLAN/RAW: /E23FB9D,0000,5A050E5C,FF,FFC8,01861023FB9D00000006010000
2014.08.01 18:40:58 5: HMLAN_Parse: HMLAN1 R:E23FB9D stat:0000 t:5A050E5C d:FF r:FFC8 m:01 8610 23FB9D 000000 06010000
2014.08.01 18:40:58 5: HMLAN1 dispatch A0D01861023FB9D00000006010000::-56:HMLAN1
2014.08.01 18:40:58 5: Triggering HMLAN1 (1 changes)
2014.08.01 18:40:58 5: Notify loop for HMLAN1 UNKNOWNCODE A0D01861023FB9D00000006010000::-56:HMLAN1
2014.08.01 18:40:58 4: eventTypes: HMLAN HMLAN1 UNKNOWNCODE A0D01861023FB9D00000006010000::-56:HMLAN1 -> UNKNOWNCODE A0D01861023FB9D00000006010000::-.*:HMLAN1
2014.08.01 18:40:58 3: HMLAN1: Unknown code A0D01861023FB9D00000006010000::-56:HMLAN1, help me!
2014.08.01 18:40:58 5: HMLAN_Send: HMLAN1 I:K
2014.08.01 18:40:58 5: HMLAN/RAW: /HHM-LAN-IF,03C1,KEQ0851857,23A46A,A20B02,5A050FDE,0008
2014.08.01 18:40:58 5: HMLAN_Parse: HMLAN1 V:03C1 sNo:KEQ0851857 d:23A46A O:A20B02 t:5A050FDE IDcnt:0008
2014.08.01 18:41:03 4: HMLAN_ack: timeout - clear queue
Ist das hilfreich?
Danke und Gruß
Hans
Entwarnung!! ;-)
Es scheint, dass der Konfig-Button ein wenig "klemmt". Ich habe das Gerät mal ein wenig weiterzerlegt ... und siehe da es funktioniert.
Vielen Dank für die Hilfe!!
Gruß
Hans