[FHEM, CUL, EM] tut irgendwie nicht wie ich denke ...
Matze
seit zwei Wochen beschäftige ich mit FHEM, CUL, EM, etc., da die erste
Heizperiode mit einer Wärmepumpe ansteht und durch eine optimale
Einstellung die Kosten für den "Spaß" locker im ersten Winter
eingespielt werden habe ich letztes WoE gleich bestellt und mich
dieses ans Werk gemacht.
Was habe ich hier:
- Conceptronics CH3SNAS
mit frischinstalliertem Debian Lenny / Kernel 2.6.30-1-orion5x (orig.
Lenny Kernel 2.6.26-2-orion5x)
- CC1101-USB-Lite 868MHz (CUL) (CULV21X)
Angeschlossen zusammen mit einem USB-Stick (2 GB) an einem passiven
USB-Hub, also ohne zusätzliche Spannungsversorgung-
Geflasht mittels FLIP mit 1.24 culfw - http://www.koeniglich.de/culfw/culfw.html
- EM 1000 WZ
Angeschlossen und Sensor EM 1000 IR leuchtet auch bei Durchlauf des
roten Balken im Zähler.
Status-LED am Sender EM 1000 S leuchtet auch alle 5 Minuten schön brav
auf für die Datenübertragung.
Nur 1er DIP auf On gestellt.
- fhem 4.6
Was soll das ganze:
Überwachung des Stromverbrauches der Heizung (Wärmepumpe) und vorallem
check wie oft diese anspringt und dann in etwa wie lange läuft (5
Minuten-Intervalle sollten reichen). Zusätzlich soll noch die
Außentemperatur und die Temperatur zweiter Innenräume gemessen werden
- hierfür dachte ich an die kostengünstigen S555TH von Conrad. Später
evtl. Vor- und Rücklauftemperatur der Heizung mittels HMS 100 T.
Wenn mal alles läuft, sollen die Daten in eine SQL-DB um sie
universieller auswerten zu können und um ggf. ein Webfrontend darauf
zu stricken.
Was funktioniert nicht:
hmmm... also, nach fast dem ganzen WoE fischen im Trüben, brauch ich
mal Eure Hilfe, entweder ich übersehe irgendwas grundlegendes oder
aber der CUL oder EM1000WZ tun nicht wie sie sollen - leider kein
weiteres unterstütztes 868er Sendegerät im Moment zur Hand.
Also, mal los:
- Rechner(chen) reboot
- CUL --> USB einstecken
Kernel-Modul cdc_acm wird automatisch geladen, mehr sollte ja nicht
notwendig sein denke ich oder muss usbserial und ftdi_sio (mit
modprobe und Parametern) zusätzlich geladen werden?
MediaStore:/home/spark-e# lsmod
Module Size Used by
ipv6 285876 14
ext2 64072 2
loop 14960 0
cdc_acm 14884 2
usb_storage 52436 1
evdev 9076 0
ehci_hcd 34472 0
usbcore 135980 4 cdc_acm,usb_storage,ehci_hcd
mv643xx_eth 26256 0
g760a 3836 0
lm75 7076 0
libphy 22860 1 mv643xx_eth
gpio_keys 4256 0
ext3 125284 1
jbd 47260 1 ext3
mbcache 8240 2 ext2,ext3
sd_mod 34324 6
crc_t10dif 1888 1 sd_mod
sata_mv 29316 3
libata 169164 1 sata_mv
scsi_mod 151196 3 usb_storage,sd_mod,libata
- screen /dev/ttyACM0
> V
V 1.24 CUL868
> t
000 00:02:56
Verständnisfrage 1: Sollte nicht hier über den Screen bereits Daten zu
"sehen" sein, wenn ein Device welche sendet oder muss ich dazu noch
irgendwas machen?
- fhem.cfg
- - - - - - - - - -
attr global logfile /usbstore/fhem/log/fhem-%Y-%m.log
attr global statefile /usbstore/fhem/devices/fhem.save # where to
save the state of the devices
attr global verbose 4 # "normal" verbosity (min 1,
max 5)
attr global port 7072 global # our TCP/IP port
(localhost only)
attr global modpath /usr/local/lib # where our FHEM
directory is
# CUL-Device
define MyCUL CUL /dev/ttyACM0 0000
define Heizung CUL_EM 1 75
attr Heizung model EMWZ
attr Heizung do_not_notify false
- - - - - - - - - - -
- FHEM starten
> fhem.pl fhem.cfg
fhem-2009-09.log
- - - - - - - - - - - -
2009.09.14 00:29:58 3: CUL opening CUL device /dev/ttyACM0
2009.09.14 00:29:58 3: CUL opened CUL device /dev/ttyACM0
2009.09.14 00:29:59 0: Server started (version 4.6 from 2009-07-03
($Id: fhem.pl,v 1.74 2009/07/03 06:53:50 rudolfkoenig Exp $), pid
1922)
- - - - - - - - - - - -
fhem.save
- - - - - - - - - - - -
#Mon Sep 14 00:29:49 2009
setstate Heizung ???
setstate global <no definition>
- - - - - - - - - - - -
Verständnisfrage 2: Wohin werden in der Grundinstallation die Daten
geschrieben? Lt. meiner Konfig würde ich in /usbstorage/fhem/devices
entsprechend ein oder mehrere Log/DB-Files erwarten.
- Telnet
> telnet localhost 7072
- - - - - - - - - - -
FHZ> list
Type list <name> for detailed info.
_internal_:
global (<no definition>)
CUL:
MyCUL (Initialized)
CUL_EM:
Heizung (???)
FHZ> list MyCUL
Internals:
DEF /dev/ttyACM0 0000
DeviceName /dev/ttyACM0
FD 6
FHTID 0000
NAME MyCUL
NR 1
PARTIAL
STATE Initialized
TYPE CUL
VERSION V 1.24 CUL868
Attributes:
repeater 1
savefirst 1
FHZ> list Heizung
Internals:
BasicFeePerMonth 0
CODE 1
CostPerUnit 0
DEF 1 75
IODev MyCUL
NAME Heizung
NR 2
STATE ???
TYPE CUL_EM
corr1 0.16
corr2 0.08
Attributes:
do_not_notify false
model EMWZ
- - - - - - - - - - -
Habe ich da was übersehen, gerade "STATE ???" scheint mir hier ein
Indiz zu sein.
Muss ich den EM 1000 WZ irgendwie am CUL registrieren, wie ich das bei
anderen 868/434er Systemen, wie z.B. Garagentor-Öffner, kenne?
Sind meine oben ausgewählten Sender/Sensoren für die jeweilige Aufgabe
geeignet?
So, nun erstmal im Voraus Danke für die Unterstützung!
Grüße,
Matze
Rudolf Koenig
> "sehen" sein, wenn ein Device welche sendet
868.35), ich kann einen der EM's bei mir nur mit diese Einstellung
empfangen. Wenn das bei Dir hilft, dann werde ich das default auch
umstellen.
Matze
danke für die prompte Antwort und Deine Mühen rund um fhem und cul!
Werde ich heute Abend mal testen, kann ich das über das telnet-
Interface von FHEM aus? Irgendwo habe ich hier schon was gelesen dazu.
Zusätzlich, sofern ich früh genug aus der Arbeit komme werde ich mir
noch drei S555TH bei Conrad besorgen, einer davon wird ja sicherlich
funktionieren, um einen weiteren Check machen zu können.
Einen FileLog für "Heizung" habe ich mir gestern auch noch
eingerichtet, Log wird angelegt aber nichts ist eingetrudelt - wie ich
erwartet hatte.
Grüße,
Matze
Stefan
Mit dem FHZ1300 geht das IMHO nicht, oder?
Rudolf Koenig
ccconf"
> Kurze Frage: die 555er Sensoren werden direkt von der CUL empfangen?
> Mit dem FHZ1300 geht das IMHO nicht, oder?
beschraenkt sich auf die Weitergabe der KS300 Funk-Telegramme aus der
S300 Familie. Diese Einschraenkung hat m.A.n. keine technischen
Gruende.
Matze
1000 WZ und sogar von meinen heute schnell bei Conrad gekauften
S555TH, die wohl im Moment für 5.- € abverkauft werden. Im aktuellen
Programm lt. dem Verkäuft ist er nicht mehr aufgeführt - er konnte ihn
nicht finden. Waren aber noch drei im Regal. Die S555TH kamen auch
erst nach der Frequenzumstellung.
So, irgendwie funken die 555er noch nicht richtig auf den Kanälen und
so 100%ig zuverlässig scheinen die nicht zu übertragen...
Was mir noch aufgefallen ist, nachdem ich FHEM per shutdown
deaktiviert hatte, hat sich mein CUL wohl aufgehängt. Erst nach einem
Abziehen und wieder Einstecken kamen wieder Daten. Weder FHEM noch per
SCREEN kam etwas.
Leider habe ich mir wohl vom CUL die zu billige Version, nur die mit
dem einfachen Kabel, ohne Antenne, geholt. Kann man die
Empfangseigenschaften noch etwas tunen?
@Rudi: 1000 Dank für die schnelle Hilfe!
Grüße,
Matze
Rudolf Koenig
> deaktiviert hatte, hat sich mein CUL wohl aufgehängt. Erst nach einem
> Abziehen und wieder Einstecken kamen wieder Daten. Weder FHEM noch per
> SCREEN kam etwas.
Versionen bekannt, bei dem jeweils aktuellen aus der CVS sollte es
nicht passieren.
> Leider habe ich mir wohl vom CUL die zu billige Version, nur die mit
> dem einfachen Kabel, ohne Antenne, geholt. Kann man die
> Empfangseigenschaften noch etwas tunen?
nach das wichtigste ist die relative Position bzw. Ausrichtung der
beiden Antennen. Und das wird mit eine zunehmende Anzahl von
Teilnehmer zunehmend kompliziert. Mit der Ausrichtung der Geraete habe
ich auch Wochen verbracht, und wehe dem, der mein CUL auch nur 5cm
verschiebt :) Natuerlich kann man das Problem mit eine dreh- und
schwenkbare Antenne eleganter loesen, als mit Draht-Verbiegen.
Du bist aber mit diesen Problemen nicht allein, noch sind das CUL
spezifisch. Deswegen auch die Diskussion in der Gruppe ueber mehrere
Empfaenger an fhem bzw. Z-Wave, bei dem die alle Geraete gleichzeitig
auch repeater bzw. router sind.
Kai 'wusel' Siering
> Zusätzlich, sofern ich früh genug aus der Arbeit komme werde ich mir
> noch drei S555TH bei Conrad besorgen, einer davon wird ja sicherlich
> funktionieren, um einen weiteren Check machen zu können.
ich habe die S300TH-Variante von Conrad mir vor ein paar Monaten
zugelegt (S 555 TH), zusätzlich zu schon vorhandenen S 300 TH von
ELV. Lustigerweise funktionieren von den, IIRC 4, gekauften 555 an-
fangs zwei nicht korrekt, kein Empfang durch meinen CUL.
Ich habe die dann liegen lassen aus Zeitmangel, wollte sie dieser
Tage (nach meinem CUL-Ausfall) dann einpacken und Conrad zurück-
schicken -- aber auf einmal funktionieren auch die beiden vormals
vermeintlich "stummen" 555er; jedenfalls empfängt mein 2., abge-
setzter CUL (socat) im OG jene einwandfrei. Lustigerweise funktio-
niert nun auch ein nach einem Einschaltvorgang stumm gewordener
Conrad-EMEM nach der mehrmonatigen Auszeit nun wirder problemlos.
Keine Ahnung, was das wieder ist. Config der CULs ist aber iden-
tisch:
FHZ> get CUL1 ccconf
CUL1 ccconf => freq:868.350MHz bWidth:325KHz rAmpl:42dB sens:4dB
FHZ> get CUL2 ccconf
CUL2 ccconf => freq:868.350MHz bWidth:325KHz rAmpl:42dB sens:4dB
Zu den EMEM eine Frage/Feststellung: bei mir haben sich zwei EMEM,
die mit Minimallasten von ~100 Watt problemlos liefen (~2h Test)
nach dem Zwischenschalten zwischen Netz und AV-Equipment (47"-LCD,
PS3, Wii, DVD, VCR -- alle auf Standby/Aus -- hängen an der Ver-
längerung, vor die ich den EMEM hängen möchte) sendetechnisch weg-
gegängt. Sprich: Verlängerung aus Wandsteckdose raus, EMEM in jene
rein, Verlängerung in EMEM => Stille. Strom floß, aber der EMEM
sendete nichts mehr. Den ersten habe ich als defekt zurückgesand,
beim zweiten erst den Funktionstest (s. o., ca. 2h mit geringer
Last) gemacht und ich dann dazwischen geschaltet. Nachdem auch der
nicht mehr sendete, habe ich ihn aus Zeitmangel liegen gelassen --
jetzt nach Monaten funktioniert er wieder bei geringer Last (~100
Watt max.)?
Ich vermute, daß der Einschaltstrom all der Geräte etwas zuviel
für dem EMEM ist; dummerweise kann ich baulicherseits das nicht
anders lösen (1 Zuleitung hinter Schrankwand). Hat schon jemand
ähnliche Erfahrungen gemacht (und vielleicht gar 'ne Lösung)?
MfG,
kai
Kai 'wusel' Siering
Da mein Kontingent an möglichen S300TH/S555TH erschöpft ist,
habe ich mir nun also 2 HMS100TF zugelegt (sowie spaßeshalber
einen FHT80B-2). Inbetriebnahme hat eigentlich auch gut ge-
klappt, der fragliche HMS steht noch neben einem S555TH, der
dann nach außen wandern wird (deutlich billiger ;)). Nur, seit
gestern abend empfängt den HMS mein CUL im gleichen Raum offen-
sichtlich nicht mehr:
FHZ> list Arbeit_TF
Internals:
CODE 07bf
DEF 07bf
IODev CUL2
NAME Arbeit_TF
NR 9
STATE T: 28 H: 41.1 Bat: ok
TYPE HMS
Readings:
2009-09-14 18:51:37 battery ok
2009-09-14 18:51:37 humidity 41.1 (%)
2009-09-14 18:51:37 temperature 28 (Celsius)
2009-09-14 18:51:37 type HMS100TF
Attributes:
IODev CUL2
model hms100-tf
room Arbeit
FHZ>
Senden tut der HMS allerdings (auch nach kurzem Batteriewechsel
zur Sicherheit), jedenfalls meine ich, entsprechende H-Meldungen
im Log auf jenen Sensor zurückführen zu können:
cam-serv2:~# grep "unknown message" /var/log/fhem/fhem-2009-09.log
2009.09.08 16:57:17 3: CUL: unknown message R1113C80380DE
2009.09.08 19:42:35 3: CUL: unknown message R1113C80380DB
2009.09.08 19:42:35 4: CUL: unknown message R1113C80380E5
2009.09.13 13:51:22 4: CUL: unknown message R1113C80380E5
2009.09.13 13:51:22 4: CUL: unknown message R1113C80380DE
2009.09.13 17:59:54 4: CUL: unknown message R1113C80380E9
[...]
2009.09.15 07:54:09 3: CUL: unknown message H07BF00654245
2009.09.15 07:54:09 4: CUL: unknown message H07BF00654245
2009.09.15 07:58:54 4: CUL: unknown message HDBF600189262
2009.09.15 07:59:22 4: CUL: unknown message H07BF00643245
2009.09.15 08:04:07 4: CUL: unknown message HDBF600188262
2009.09.15 08:04:35 4: CUL: unknown message H07BF00635245
(DBF6 ist der zweite HMS, der im EG im Kinderzimmer steht und dem
FHZ im EG zugeordnet ist:
FHZ> list Kinder_TF
Internals:
CODE dbf6
DEF dbf6
IODev FHZ1
NAME Kinder_TF
NR 4
STATE T: 21.7 H: 62.7 Bat: ok
TYPE HMS
Readings:
2009-09-15 08:14:32 battery ok
2009-09-15 08:14:32 humidity 62.7 (%)
2009-09-15 08:14:32 temperature 21.7 (Celsius)
2009-09-15 08:14:32 type HMS100TF
Attributes:
model hms100-tf
room Kinder
Der funktioniert also.)
fhem:~# grep -B 1 "unknown message" /var/log/fhem/fhem-2009-09.log | tail -20
2009.09.15 07:58:54 4: CUL2: HDBF600189262 -55.5
2009.09.15 07:58:54 4: CUL: unknown message HDBF600189262
--
2009.09.15 07:59:22 4: CUL2: H07BF00643245 -53
2009.09.15 07:59:22 4: CUL: unknown message H07BF00643245
--
2009.09.15 08:04:07 4: CUL2: HDBF600188262 -56.5
2009.09.15 08:04:07 4: CUL: unknown message HDBF600188262
--
2009.09.15 08:04:35 4: CUL2: H07BF00635245 -52
2009.09.15 08:04:35 4: CUL: unknown message H07BF00635245
--
2009.09.15 08:09:20 4: CUL2: HDBF600187262 -56.5
2009.09.15 08:09:20 4: CUL: unknown message HDBF600187262
--
2009.09.15 08:09:48 4: CUL2: H07BF00631246 -52
2009.09.15 08:09:48 4: CUL: unknown message H07BF00631246
--
2009.09.15 08:15:01 3: CUL1: H07BF00625246 -88
2009.09.15 08:15:01 3: CUL: unknown message H07BF00625246
Any ideas, warum FHEM von CUL2 das Datagram des HMS im gleichen
Raum nicht auswertet?
Und, interessehalber, was sind die R-Geräte, die ich mal emfpangen
habe, RM100 eines Nachbarn?
Danke & Ciao,
kai
Matze
> > deaktiviert hatte, hat sich mein CUL wohl aufgehängt. Erst nach einem
> > Abziehen und wieder Einstecken kamen wieder Daten. Weder FHEM noch per
> > SCREEN kam etwas.
>
> Welche Version von culfw & fhem war das? Das Problem war beim aelteren
> Versionen bekannt, bei dem jeweils aktuellen aus der CVS sollte es
> nicht passieren.
> > Leider habe ich mir wohl vom CUL die zu billige Version, nur die mit
> > dem einfachen Kabel, ohne Antenne, geholt. Kann man die
> > Empfangseigenschaften noch etwas tunen?
>
> Siehe die Datei FREQTEST im culfw. Meiner Ansicht (bzw. Experimente)
> nach das wichtigste ist die relative Position bzw. Ausrichtung der
> beiden Antennen. Und das wird mit eine zunehmende Anzahl von
> Teilnehmer zunehmend kompliziert. Mit der Ausrichtung der Geraete habe
> ich auch Wochen verbracht, und wehe dem, der mein CUL auch nur 5cm
> verschiebt :) Natuerlich kann man das Problem mit eine dreh- und
> schwenkbare Antenne eleganter loesen, als mit Draht-Verbiegen.
hat längere Zeit keine Daten gehabt. Na, dann heisst es jetzt wohl die
richtigen Positionen finden.
Danke für die Infos
Matze
Kai 'wusel' Siering
> dann nach außen wandern wird (deutlich billiger ;)). Nur, seit
> gestern abend empfängt den HMS mein CUL im gleichen Raum offen-
> sichtlich nicht mehr:
Wahrscheinlich hat es das auch nie, die Meldung kam wohl eher von
der FHZ; jedenfalls finde ich kein Modul CUL_HMS, also heißt es
wohl, das 12_HMS.pm zu einem 16_CUL_HMS.pm zu transformieren? Empfangen
wird das HMS-Telegramm ja, oder?
> 2009.09.15 07:54:09 3: CUL: unknown message H07BF00654245
> 2009.09.15 07:58:54 4: CUL: unknown message HDBF600189262
Nachdem ich heute morgen IODev jeweils auf einen CUL stellte, wird
nun auch der zweite, ehemals von der FHZ bediente, HMS nicht mehr
ausgewertet -- Eigentor ;)
.oO( Irgendwann werde ich die Funktionsweise von FHEM bestimmt ver-
innerlicht haben. Ehrlich! ;) )
Ciao,
kai
Rudolf Koenig
prueft, sondern die Telegramme nur an der Laenge erkennt (4Byte+4Bit).
Das ist in diesem Fall wahrscheinlich was anderes.
> 2009.09.15 07:54:09 3: CUL: unknown message H07BF00654245
Nachricht konvertieren, und sie an das 12_HMS weiterreichen. Bei mir
tut es jedenfalls.
> jedenfalls finde ich kein Modul CUL_HMS, also heißt es
> wohl, das 12_HMS.pm zu einem 16_CUL_HMS.pm zu transformieren?
Fuer EM oder WS waere das viel komplizierter, deswegen gibt es die
CUL_EM bzw. CUL_WS Module.
> Nachdem ich heute morgen IODev jeweils auf einen CUL stellte, wird
>nun auch der zweite, ehemals von der FHZ bediente, HMS nicht mehr
> ausgewertet -- Eigentor ;)
moeglichst aktuellen culfw und 00_CUL.pm nehmen. Dann muss man noch
die FHT's mit dem CUL "verheiraten", und am besten keinen FHZ parallel
mitlaufen lassen, da dieser staendig reinredet. Wenn der CUL nicht mit
dem FHT's reden soll, dann sollte der ID bei der CUL Definition 0000
sein.
Kai 'wusel' Siering
>> 2009.09.15 07:54:09 3: CUL: unknown message H07BF00654245
> Eigentlich sollte ein aktuelles (d.h. ca ab August 2009) 00_CUL.pm die
> Nachricht konvertieren, und sie an das 12_HMS weiterreichen. Bei mir
> tut es jedenfalls.
Okay, mein FHEM ist älter. Dann steht wohl ein Update an ...
>> Nachdem ich heute morgen IODev jeweils auf einen CUL stellte, wird
>> nun auch der zweite, ehemals von der FHZ bediente, HMS nicht mehr
>> ausgewertet -- Eigentor ;)
> Wenn man die FHT's ueber den CUL steuern will, dann sollte man einen
> moeglichst aktuellen culfw und 00_CUL.pm nehmen. Dann muss man noch
> die FHT's mit dem CUL "verheiraten", und am besten keinen FHZ parallel
> mitlaufen lassen, da dieser staendig reinredet. Wenn der CUL nicht mit
> dem FHT's reden soll, dann sollte der ID bei der CUL Definition 0000
> sein.
Nee, derzeit ist HMS nur als -FT, als Erweiterung zu den S300THs,
geplant. FHT ist mal zum rumspielen (»begreifen kommt von anfas-
sen«); das bißchen, was wir heizen (lagebedingt geringer Heizbedarf
bei Sonnenschein, auch im Winter), kriegen wir auch mit den Thermos-
taten hin ;) Noch jedenfalls; evtl. bietet sich ein FHT-Setup für die
Praxis meiner Frau an, da beginnt es schon, empfindlich kalt zu wer-
den dieser Tage. Ergo: FHTs dürfen gerne von FHZ bedient werden, die
HMS allerdings müssen zum. zum Teil von CULs bedient werden.
(Hmm, wenn ich 'n socat für die FritzBox kompiliert bekäme, könnte
der heimische FHEM via CUL in der Praxis allerdings Steuerung/Da-
tenerhebung über's Netz erledigen ... Hmmm ... wäre cool ;) Man
braucht je Raum eine FHT80B? Naja, Set-Preis liegt ja relativ
günstig.)
kai
Matze
define Heizung CUL_EM 1 XX
Die letzte Ziffer (hier XX) gibt den Korrekturfaktor an, bzgl.
Umdrehungen/kWh, diese ist bei meinem Zähler 75, was für einen
Korrekturfaktor trage ich dort ein um im Log dann auch die (k)Wh zu
sehen?
define Heizung CUL_EM 1 13.33
Eine Umdrehung sind in meinem Fall 13,33 Wh, richtig?
oder aber ala Doku "for EMWZ devices you should specify the rotation
speed (R/kW) of your watt-meter (e.g. 150)"
define Heizung CUL_EM 1 75
Zeit 45.000 kWh auf der Uhr :-)
Grüße,
Matze
Rudolf Koenig
define emwz CUL_EM 1 75 900
Das mit dem 900 ist nicht unbedingt schoen (900 = 12*75), das gebe ich
zu.
Matze
Umdrehungen des Zählers pro kWh * Zähleinheiten pro Stunde =
Korrekturfaktor
75 * 12 (alle 5 Minuten) = 900
Das sollte dann aber so in die Doku - kein Meckern! Bin froh, dass es
fhem gibt :)
Aber eben wieder den Fall gehabt, fhem shutdown bzw. da nicht root
gewesen Probleme mit den Rechten und Dienst bei "rereadcfg" quittiert,
danach keine Daten. CUL raus und wieder rein und dann wieder ok.
Grüße,
Matze