Bausatz HM_Sen_RD_O

[marc2]

Hallo Martin,

es sind das Device und beide Channels definiert:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[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.


statusRequest auf die Channels funktionieren nicht, da bekomme ich auch nur NACK im Device.

[martinp876]

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.

[betateilchen]

Hallo Martin,

die Logmeldung kommt bei "rain" kommt gar nicht mehr.

Code Auswählen Erweitern

Ich denke daran das Attribut "peerIDs" aus reinen Devices zu löschen.

bitte nicht...

[betateilchen]

Code Auswählen Erweitern


# $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.

[martinp876]

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

[betateilchen]

Warum 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?

[martinp876]

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

[betateilchen]

Ich 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.

[martinp876]

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

[betateilchen]

(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.

[martinp876]

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

[marc2]

Hallo Martin !

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

Warum hast Du den Statusrequest komplett entfernt ? Zumindest für die Heizung macht es Sinn und hat
auch funktioniert.

Gruß, Marc

[martinp876]

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

[marc2]

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:

Code Auswählen Erweitern

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