Hallo zusammen,
wird es eine Unterstützung für das neue HomeMatic Produkt HM-ES-TX-WM geben?
Grüße
Oliver
Get hm models -f TX
Hallo martinp876,
welches Modul muss ich denn updaten um neue hm-Modelle "nachzuladen"?
Weil mir die fritzbox beim Update eigentlich immer abstürzt, wollte ich nur das Modul 10_CUL_HM.pm updaten. Das hat aber leider keine neuen HM-Komponenten nachinstalliert. Auch das zusätzliche Update von 00_HMLAN.pm brachte nix. Erst ein komplettes Update (eigentlich 2 abgebrochene Updateversuche incl. 2x FB-Neustart) haben dann geholfen. Naja jetzt ist fhem jedenfalls wieder up-to-date ;D
Aber mal so interessehalber: Was hätte ich denn alles aktualisieren müssen?
Übrigens mal wieder vielen Dank für deine Super-Arbeit!
Gruß StefanP
Zitat von: StefanP am 31 Januar 2015, 19:40:35Weil mir die fritzbox beim Update eigentlich immer abstürzt
Keine sonderlich gute Voraussetzung für ne stabile Steuerung eigentlich. Das muss doch irgendeinen Grund haben?
ZitatDas hat aber leider keine neuen HM-Komponenten nachinstalliert.
Ich glaube Martin wollte damit aussagen dass er das Teil auf dem Schirm hat und unterstützen wird sobald es Hardware gibt. Code gibt es für das Ding meines Wissens noch nicht.
ZitatIch glaube Martin wollte damit aussagen dass er das Teil auf dem Schirm hat und unterstützen wird sobald es Hardware gibt. Code gibt es für das Ding meines Wissens noch nicht.
Wollte er ziemlich sicher nicht.
Get hm models -f TXlistet das Teil ja jetzt auf.
ZitatKeine sonderlich gute Voraussetzung für ne stabile Steuerung eigentlich. Das muss doch irgendeinen Grund haben?
Is' schon klar; aber da ich fhem eh' umziehen möchte, investiere ich keinen Aufwand mehr in Fehlersuche.
Gruß StefanP
Zitat von: StefanP am 31 Januar 2015, 20:31:58
Wollte er ziemlich sicher nicht.
Get hm models -f TXlistet das Teil ja jetzt auf.
Das macht es seit 1. November 2014. Deswegen gibt's trotzdem noch keinen Code dafür.
Irgendwie verstehe ich deine Aussage nicht.
commandref hminfo:
ZitatGet ◦models
list all HM models that are supported in FHEM
Danach hatte octek0815 doch wohl gefragt.
Ich habe danach gefragt, welche Module ich für neue HM-Hardware updaten muß.
Was du mit "Code" meinst, keine Ahnung; aber vielleicht kannst Du mir ja trotzdem meine Frage beantworten.
Vorab vielen Dank
Gruß StefanP
Ich würde es mal mit folgende versuchen:
HMConfig.pm
00_HMLAN.pm
10_CUL_HM.pm
98_HMinfo.pm
Danke!
Zitat von: StefanP am 31 Januar 2015, 21:17:30
Irgendwie verstehe ich deine Aussage nicht.
Ok, nochmal: das Ding taucht in der Liste auf, ist aber noch nicht implementiert. Die Tatsache dass es in der Liste auftaucht weißt aber darauf hin dass es in Zukunft mal funktionieren soll. Denn das war die Ausgangs-Frage "Wird es in Zukunft mal unterstützt?"
Zitatlist all HM models that are supported in FHEM
Es gibt faktisch keine Releases von FHEM, nur eine Entwickler-Version. Der muss man nicht immer alles glauben ;)
ZitatIch habe danach gefragt, welche Module ich für neue HM-Hardware updaten muß.
Stromers Liste dürfte passen. Im Fall von HM-ES-TX-WM bringt's halt noch nichts.
Hm models ist die komplette liste der unterstuetzten devices. Im gegensatz zu docu ist es live info, also real. Auch zu sehen sind kommandos und register.
Unbekannte bugs sind nicht gelistet :)
Gut, Du bist natürlich der Spezialist für Deinen Code und dass die paar Register definiert waren hab ich schon gesehen, aber ich sehe nicht wo z.B. für das -TX Device irgendwelche Events generiert werden?
@martinp876,
danke für die Klarstellung.
ZitatUnbekannte bugs sind nicht gelistet :)
Im nächsten Release? ;)
Gruß StefanP
stimmt, für event gibt es keine Zusammenstellung.
was du aber annehmen kannst ist: wenn ein Sensor trigger sendet (limit Überschreitung o.ä.) werden diese wir bei allen sensoren betrieben. Meldung aktueller Werte werden voraussichtlich wie bei jedem Sensor kommen - FHEM setzt nur die Readings, was immer der Sensor so von sich gibt. Ob das funktioniert musst du bei eQ3 nachfragen.
da FHEM keinen Einblick in die Entwicklung bei eQ3 hat wird die ganze wahrheit erst klar, wenn einer das Device aktiviert. Bei einem einfachen Device wie diesem Sensor sind eher keine Überraschungen zu erwarten.
Für mich ist der einzige Zweck eines Meter-Sensors den Wert über die Zeit zu loggen und evtl noch die 1. Ableitung zu bilden. Das geht stand heute noch nicht, insofern ist es für meine Zwecke einfach noch nicht fertig. Dass das nur eine kleine Fingerübung für Dich sein wird sobald mal reale Hardware gesehen wurde glaub ich Dir sofort und bin auch sehr dankbar dass Du das, teilweise ohne die Hardware selbst zu besitzen, bisher immer alles übernimmst!
Wie dem auch sei, bin schon sehr gespannt ob ELV zum neuen Termin mitte Februar dann auch endlich mal liefern kann...
wie hast du das getestet? Du hast doch noch keins...?
wenn, dann schicke einmal logs
Nichts getestet, ich hab nur den Code gelesen und das war meine Interpretation des status quo. Logs gibt's gerne sobald ELV mal liefert.
Hardware ist unterwegs :)
Bei mir kam auch die Mail mit der Versandbestätigung. :D
meins kam heute an
Meins sollte auch heute ankommen, normalerweise ist die DHL auch um ca. 12:30Uhr da. Vermutlich steckt das Auto irgendwo fest.
Paket wurde heute Mittag geliefert.
Gesendet von meinem GT-I9295
So, erstmal zusammengebaut und Probeweise einen Sensor vom ESA2000WZ angeklemmt.
Sensor wurde sofort erkannt mit voreingestellten 100 Umdrehungen. Ansprechempfindlichkeit und Umdrehsanzahl eingestellt und er zeigte den aktuellen Verbrauch schon mal an.
So, hier mal ein List des Devices mit dem Gaszählersensor vom ESA1000Z betrieben.
Internals:
CFGFN
DEF xxxxxx
IODev hmlan_1
LASTInputDev hmusb_1
MSGCNT 124
NAME CUL_HM_HM_ES_TX_WM_xxxxxx
NR 4129
STATE NACK
TYPE CUL_HM
hmlan_1_MSGCNT 65
hmlan_1_RAWMSG Exxxxxx,0000,06BA19D8,FF,FFD0,058653xxxxxx00000000000014000263
hmlan_1_RSSI -48
hmlan_1_TIME 2015-02-05 19:41:39
hmusb_1_MSGCNT 59
hmusb_1_RAWMSG Exxxxxx,0000,67F790BD,FF,FFC2,058653xxxxxx00000000000014000263
hmusb_1_RSSI -62
hmusb_1_TIME 2015-02-05 19:41:39
lastMsg No:05 - t:53 s:xxxxxx d:000000 00000014000263
protCmdDel 3
protErrIoAttack 1 last_at:2015-02-05 19:10:47
protLastRcv 2015-02-05 19:41:39
protNack 2 last_at:2015-02-05 19:31:29
protSnd 38 last_at:2015-02-05 19:41:28
protState CMDs_done
rssi_at_hmlan_1 avg:-60.76 min:-80 max:-43 lst:-48 cnt:65
rssi_at_hmusb_1 avg:-51.72 min:-66 max:-37 lst:-62 cnt:59
CHANGETIME:
Helper:
Dblog:
Activity:
Mydblog:
TIME 1423161561.48744
VALUE alive
D-firmware:
Mydblog:
TIME 1423161561.48744
VALUE 1.0
D-serialnr:
Mydblog:
TIME 1423161561.48744
VALUE MEQ0025208
R-mtrsensir:
Mydblog:
TIME 1423161562.27695
VALUE 0
R-mtrtype:
Mydblog:
TIME 1423161562.27695
VALUE gas
R-paircentral:
Mydblog:
TIME 1423159848.42442
VALUE 0xyyyyyy
Boot:
Mydblog:
TIME 1423161567.51564
VALUE off
Current:
Mydblog:
TIME 1423160817.54884
VALUE 0
Estate:
Mydblog:
TIME 1423161567.51564
VALUE E: 0.02 P: 0.611
Energy:
Mydblog:
TIME 1423160817.54884
VALUE 0
Energyoffset:
Mydblog:
TIME 1423159964.61576
VALUE 0
Frequency:
Mydblog:
TIME 1423160817.54884
VALUE 50
Gascnt:
Mydblog:
TIME 1423161567.51564
VALUE 0.02
Gaspower:
Mydblog:
TIME 1423161567.51564
VALUE 0.611
Power:
Mydblog:
TIME 1423160817.54884
VALUE 0
Poweron:
Mydblog:
TIME 1423159964.61576
VALUE 2015-02-05 19:12:44
Sabotageattack:
Mydblog:
TIME 1423159847.4375
VALUE ErrIoAttack cnt:1
State:
Mydblog:
TIME 1423161089.0589
VALUE NACK
Voltage:
Mydblog:
TIME 1423160817.54884
VALUE 0
Readings:
2015-02-05 19:41:27 Activity alive
2015-02-05 19:41:27 D-firmware 1.0
2015-02-05 19:41:27 D-serialNr MEQ0025208
2015-02-05 19:41:27 PairedTo 0xyyyyyy
2015-02-05 19:41:28 R-mtrConstGas 0.01 m3/I
2015-02-05 19:41:28 R-mtrConstIr 600 U/kWh
2015-02-05 19:41:28 R-mtrConstLed 10000 i/kWh
2015-02-05 19:41:28 R-mtrSensIr 0 %
2015-02-05 19:41:28 R-mtrType gas
2015-02-05 19:41:27 R-pairCentral 0xyyyyyy
2015-02-05 19:41:27 RegL_00: 02:01 63:7A 0A:71 0B:39 0C:02 8A:5E 14:06 00:00
2015-02-05 19:41:28 RegL_01: 08:00 30:06 95:01 96:02 97:58 98:00 99:0A 9A:27 9B:10 9C:00 00:00
2015-02-05 19:41:39 boot off
2015-02-05 19:41:39 eState E: 0.02 P: 0.611
2015-02-05 19:41:39 gasCnt 0.02
2015-02-05 19:41:39 gasPower 0.611
Helper:
cSnd 01yyyyyyxxxxxx01040000000001
getCfgListNo
mId 00DE
rxType 12
Io:
newChn +xxxxxx,00,01,00
nextSend 1423161699.20047
prefIO
rxt 2
vccu
p:
xxxxxx
00
01
00
Mrssi:
mNo 05
Io:
hmlan_1 -46
hmusb_1 -62
Prt:
bErr 0
sProc 0
try 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlan_1:
avg -60.7692307692308
cnt 65
lst -48
max -43
min -80
At_hmusb_1:
avg -51.728813559322
cnt 59
lst -62
max -37
min -66
Shadowreg:
Attributes:
DbLogExclude .*
IODev hmlan_1
IOgrp vccu:hmlan_1
actCycle 000:10
actStatus alive
autoReadReg 5_readMissing
expert 2_full
firmware 1.0
model HM-ES-TX-WM
room 9_9_CUL_HM
serialNr MEQ0025208
subType powerSensor
ZitatRegL_00: 02:01 63:7A 0A:71 0B:39 0C:02 8A:5E 14:06 00:00
die hmid unkenntlich machen, ist eigentlich völlig überflüssig, weil die sowieso jeder loggen kann. da braucht man wahscheinlich nur 2-5 funkmessages und du weisst was los ist. da finde ich die seriennummer schon relevanter. besonders bei devices (non battery) die man über seriennummer pairen kann. aber selbst die wird ein geduldiger nachbar irgendwann kennen.
Schlecht bei dem Teil gelöst, das man das Batteriefach ablöten muß um an die Messpunkte zu kommen.
Der Gassensor will nicht so recht. Ich habe an der Buchse nur 3.2V laut Anleitung sollen aber 4.4V sein.
Ich betreibe den Energiesensor jetzt an meinen Drehstromzähler mit Ferrarischeibe, da funktioniert er.
Beim Gaszähler muss vermutlich die Widerstandskombi angepasst werden.
Ich bekomme da keinen Impuls gezählt. Flanke ist mit den angegeben Widerständen bei ca 1,86V nach 0V.
Bei mir wird kein Batteriestatus mitgesendet. Wird der wirklich nicht gesendet oder fehlt der in der FHEM-Implementierung?
So, Gerät ist gebaut, allerdings fehlt mir noch ein Sensor, die 50€ für das Gas-Teil waren mir dann doch zu heavy. Laut Anleitung besteht er auch aus ganzen 5 Teilen:
- 3 Widerstände (10k, 100k, 150k). Der 150k ist interessanterweise nicht in der Stückliste
- Ein Reed-Kontakt (IN-Z62, ich werd's mit nem 1,50€ Teil von Reichelt versuchen)
- Ein 6P6C Western Kabel. Leider hab ich nur 6P4C rumliegen, daher muss der Nachbau auf Morgen warten
Bin gespannt ob's ein Materialaufwand von rund 2,50€ am Ende auch tut...
könnt ihr einmal rohmessages aufzeichnen? Auch ein getConfig. Register Adressen sind seltsam - nicht dokumentiert....
und ein paar "Messungen"
Also die Zählung mit dem Gas-Sensor funktioniert noch nicht ganz so wie ich's mir vorgestellt habe, aber hier mal ein GetConfig (TX als Gas-Sensor):
2015.02.06 18:48:16.319 3: CUL_HM set Gas getConfig
2015.02.06 18:48:22.232 0: HMLAN_Parse: HMLAN1 R:E35357D stat:0000 t:10E2075F d:FF r:FFCD m:9D 8400 35357D 000000 1000DE4D45513030323534373551010101
2015.02.06 18:48:22.324 0: HMLAN_Send: HMLAN1 S:+35357D,02,01,1E
2015.02.06 18:48:22.324 0: HMLAN_Send: HMLAN1 S:S6001C0A7 stat: 00 t:00000000 d:01 r:6001C0A7 m:9D A001 25742C 35357D 00040000000000
2015.02.06 18:48:22.500 0: HMLAN_Parse: HMLAN1 R:E35357D stat:0000 t:10E20869 d:FF r:FFCD m:9D A010 35357D 25742C 020201D1E80A250B740C2C915814060000
2015.02.06 18:48:22.607 0: HMLAN_Parse: HMLAN1 R:R6001C0A7 stat:0001 t:10E2086E d:FF r:FFCD m:9D A010 35357D 25742C 020201D1E80A250B740C2C915814060000
2015.02.06 18:48:22.609 0: HMLAN_Send: HMLAN1 S:+35357D,02,01,1E
2015.02.06 18:48:22.609 0: HMLAN_Send: HMLAN1 S:S6001C21C stat: 00 t:00000000 d:01 r:6001C21C m:9E A001 25742C 35357D 01040000000001
2015.02.06 18:48:23.025 0: HMLAN_Parse: HMLAN1 R:E35357D stat:0000 t:10E20A76 d:FF r:FFD0 m:9E A010 35357D 25742C 0208003006950196009764980099019A27
2015.02.06 18:48:23.132 0: HMLAN_Parse: HMLAN1 R:R6001C21C stat:0001 t:10E20A7B d:FF r:FFD0 m:9E A010 35357D 25742C 0208003006950196009764980099019A27
2015.02.06 18:48:23.224 0: HMLAN_Parse: HMLAN1 R:E35357D stat:0000 t:10E20B3F d:FF r:FFD0 m:9E A010 35357D 25742C 029B109C000000
Und paar Messungen
2015.02.06 18:49:22.047 0: HMLAN_Parse: HMLAN1 R:E35357D stat:0000 t:10E2F10D d:FF r:FFCB m:05 8653 35357D 000000 00000054001E92
2015.02.06 18:52:04.895 0: HMLAN_Parse: HMLAN1 R:E35357D stat:0000 t:10E56D41 d:FF r:FFC5 m:06 8653 35357D 000000 00000055000004
2015.02.06 18:54:33.827 0: HMLAN_Parse: HMLAN1 R:E35357D stat:0000 t:10E7B318 d:FF r:FFC7 m:07 8653 35357D 000000 0000005700038F
2015.02.06 18:56:48.599 0: HMLAN_Parse: HMLAN1 R:E35357D stat:0000 t:10E9C19C d:FF r:FFCC m:08 8653 35357D 000000 0000005700038F
Zitat von: stromer-12 am 05 Februar 2015, 20:42:40
Der Gassensor will nicht so recht. Ich habe an der Buchse nur 3.2V laut Anleitung sollen aber 4.4V sein.
Kann ich bestätigen. Der Spannungsabfall erfolgt alleine an T3. Analog-Technik ist vielleicht nicht meine Stärke, aber das kommt mir extrem spanisch vor. Hat da jemand zur falschen SMD Rolle gegriffen? Die Chip-Markierung passt auch nicht zum Originalteil.
ZitatBeim Gaszähler muss vermutlich die Widerstandskombi angepasst werden.
Ich bekomme da keinen Impuls gezählt. Flanke ist mit den angegeben Widerständen bei ca 1,86V nach 0V.
Mit anderen Widerständen zählt er zwar etwas bei mir, aber irgendwie nicht einzelne Impulse sondern gleich tausende... alles noch sehr seltsam.
Nach etwas überlegen vermute ich das T3 taktet und die Widerstandskombi nur Impulsweise Strom bekommt wegen Stromsparens. Ich hatte nur 3 Impulse obwohl es über 100 hätten sein müssen.
Das ist ne gute Theorie, allerdings sagt mir mein Oszi dass da nix taktet. Zumindest nicht <20Mhz ;)
Mmh, Oszi habe ich leider keinen.
Zitat von: stromer-12 am 07 Februar 2015, 12:20:01
Mmh, Oszi habe ich leider keinen.
Man kann's auch daran merken dass die Gate-Spannung konstant rund 4,3 Volt hat, die müsste ja dann auch niedriger sein.
Du hast es mit dem Original Gas-Sensor versucht?
Ich habe den ESA1000GAS Sensor, der Ist schaltungstechnisch identsch aufgebaut. Er wird auch erkannt als "GAS" nach dem eilegen der Batterien.
Am ESA1000 funktioniert der Sensor ohne Probleme. Es ist der IN-Z62 Reedkontakt.
Also mein 2,50€ Gas-Zähler funktioniert doch wie er soll ;) Ich hatte nur nicht verstanden was die Anzeige am Gas-Zähler soll (in m³)... ich denke das müsste eigentlich m³/h heißen, dann macht's mehr Sinn, das ist nämlich der Momentanverbrauch.
@stromer: R2 (150kOhm) muss dafür raus. Deswegen fehlt er auch in der Bestückungsliste.
Zitat von: MarcelK am 10 Februar 2015, 23:59:14
@stromer: R2 (150kOhm) muss dafür raus. Deswegen fehlt er auch in der Bestückungsliste.
In die Bestückungsliste hatte ich gar nicht geschaut, nur auf den Plan.
R2 ausgelötet und der ES-TX zählt fleißig die Impulse.
Gibt es eigentlich einen Offset für den Zähler wie bei der Strommessung?
Zitat von: stromer-12 am 14 Februar 2015, 20:01:53
Gibt es eigentlich einen Offset für den Zähler wie bei der Strommessung?
Laut Code leider nein, das ist aber auch eine reine FHEM Sache und hat nichts mit dem Device zu tun. Könnte man für Gas im Prinzip genauso machen.
ist eingebaut (gas-offset).
unklar ist die erkennung des power-up. hier wäre ein log cool, wenn das gerät gebootet wird
Hallo,
kann jemand mal eine Info geben, wie oft das Teil die Verbrauchswerte (als Stromzähler) sendet? Bei meinem alten ESA1000WZ-LED sind die Abstände immer mindestes 3 Minuten, das ist mir manchmal etwas zu wenig.
Zitat von: martinp876 am 15 Februar 2015, 16:56:02
ist eingebaut (gas-offset).
unklar ist die erkennung des power-up. hier wäre ein log cool, wenn das gerät gebootet wird
Danke Martin, scheint hier nach einmal Batterie raus/rein bereits funktioniert zu haben.
Hier das Boot-Log:
2015.02.16 21:15:24.807 0: HMLAN_Parse: HMLAN1 R:E35357D stat:0000 t:178D8999 d:FF r:FFAE m:00 A610 35357D 25742C 06010000
2015.02.16 21:15:25.082 0: HMLAN_Parse: HMLAN1 R:E35357D stat:0000 t:178D8AAC d:FF r:FFAE m:01 A654 35357D 25742C 80000000000000
Zitat von: fruemmel am 16 Februar 2015, 16:15:37
kann jemand mal eine Info geben, wie oft das Teil die Verbrauchswerte (als Stromzähler) sendet? Bei meinem alten ESA1000WZ-LED sind die Abstände immer mindestes 3 Minuten, das ist mir manchmal etwas zu wenig.
Im Gas-Modus sind's alle 2-3 Minuten, denke mal das ist bei Strom nicht anders.
Laut Dokumentation wie beim ESA alle 2 bis 3 Minuten.
Gesendet von meinem GT-I9295
2-3min ist die hm standardzeit zum messen. Die zeit wird nach einem algorithmus variiert, das sorgt fuer eine bessere verteilung
Hallo.
Ich habe dieses Modul auch heute zusammenbaut und auf meinem Gaszähler mit dem ELV Sensor montiert.
Meiner hat folgende Einstellung: 1 imp = 0,1m³.
Den Wert auf dem Modul eingestellt und er zählte sofort.
Perfekt.
Ich habe mir ein neues Reading mit setreading angelegt um den aktuellen Zählerstand zu bekommen.
setreading <device> gasCntOffset 15572.20
Auch ein neues User-Reading wurde angelegt.
userReadings gasVolume { ReadingsVal($name,"gasCnt",0) +ReadingsVal($name,"gasCntOffset",0) }
Damit zählt er genau hoch.
Was mir nicht klar ist.
Was bedeutet der Wert gasPower 0.638 ?
Meine CFG:
AME CUL_HM_HM_ES_TX_WM_3533EF
NR 181
STATE 0
TYPE CUL_HM
lastMsg No:E0 - t:53 s:3533EF d:000000 00000FA000027E
protLastRcv 2015-02-23 00:09:46
rssi_at_HMLAN1 avg:-67.09 min:-68 max:-66 lst:-68 cnt:10
Readings:
2015-02-22 23:46:58 Activity alive
2015-02-22 15:43:07 CommandAccepted yes
2015-02-22 15:43:05 D-firmware 1.0
2015-02-22 15:43:05 D-serialNr MEQ0025673
2015-02-22 15:43:07 PairedTo 0x29A498
2015-02-22 15:36:12 R-mtrConstGas 0.1 m3/I
2015-02-22 15:36:12 R-mtrConstIr 100 U/kWh
2015-02-22 15:36:12 R-mtrConstLed 10000 i/kWh
2015-02-22 15:36:12 R-mtrSensIr 0 %
2015-02-22 15:36:12 R-mtrType gas
2015-02-22 15:43:07 R-pairCentral 0x29A498
2015-02-22 15:36:11 R-transmDevTryMax 6
2015-02-22 15:36:12 R-transmitTryMax 6
2015-02-22 15:43:07 RegL_00: 02:01 32:64 0A:29 0B:A4 0C:98 2E:39 14:06 00:00
2015-02-22 15:43:08 RegL_01: 08:00 30:06 95:01 96:00 97:64 98:00 99:64 9A:27 9B:10 9C:00 00:00
2015-02-22 15:43:07 aesKeyNbr 00
2015-02-23 00:09:46 boot off
2015-02-23 00:09:46 eState E: 4 P: 0.638
2015-02-23 00:09:46 gasCnt 4
2015-02-22 15:48:27 gasCntOffset 15572.20
2015-02-23 00:09:46 gasPower 0.638
2015-02-23 00:09:46 gasVolume 15576.2
Helper:
mId 00DE
rxType 12
Io:
newChn +3533EF,00,01,00
nextSend 1424646586.53912
prefIO
rxt 2
vccu
p:
3533EF
00
01
00
Mrssi:
mNo E0
Io:
HMLAN1 -66
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlan1:
avg -67.1
cnt 10
lst -68
max -66
min -68
Attributes:
IODev HMLAN1
actCycle 000:10
actStatus alive
alias Gaszaehler1
autoReadReg 4_reqStatus
expert 2_full
firmware 1.0
model HM-ES-TX-WM
room CUL_HM,Zähler
serialNr MEQ0025673
subType powerSensor
userReadings gasVolume { ReadingsVal($name,"gasCnt",0) +ReadingsVal($name,"gasCntOffset",0) }
Zitat von: pipp37 am 23 Februar 2015, 00:22:29
Was bedeutet der Wert gasPower 0.638 ?
Meiner Meinung nach ist das der aktuelle Verbrauch in m³/h.
Das es der aktuelle Verbrauch ist, dachte ich auch schon.
Allerdings blieb der Wert von gasPower mit 0.638 die ganze Nacht über gleich, obwohl die Heizung bis am Morgen abgeschaltet war und sich auch der Wert gasCnt, der ja die Umdrehungen zählt, den ganzen Zeitaum nicht geändert hat.
Der sollte meiner Meinung nach wohl auf 0 sinken, oder?
Zitat von: pipp37 am 23 Februar 2015, 11:06:13
Allerdings blieb der Wert von gasPower mit 0.638 die ganze Nacht über gleich, obwohl die Heizung bis am Morgen abgeschaltet war und sich auch der Wert gasCnt, der ja die Umdrehungen zählt, den ganzen Zeitaum nicht geändert hat.
Ja, eben weil sich gasCnt nicht ändert ändert sich gasPower auch nicht, weil der Wert nur bei einem neuen Impuls aktualisiert wird. Recht dämlich aber ist erstmal so. Meine derzeitige Lösung dazu gibt's im anderen Thread zum Zähler hier im Forum.
Edit: Ab hier http://forum.fhem.de/index.php/topic,30936.msg260721.html#msg260721 (http://forum.fhem.de/index.php/topic,30936.msg260721.html#msg260721)
Ich habe jetzt seit ein paar Wochen den Stromzähler in Benutzung. Und da mein Strom verbrauch relativ hoch ist, ist heute morgen der Zähler für energy übergelaufen.
Der Zähler energy läuft bei genau 838860.7 über. Das entspricht 0x7FFFFF.
Ich habe das so gelöst das ich zwei neue user attribute angelegt habe.
attr Strom_Zaehler overflow 1
attr Strom_Zaehler overflowvalue 838860.7
Und dann die kWh wie folgt berechne
attr Strom_Zaehler userReadings kWh {sprintf("%.2f",(ReadingsVal("Strom_Zaehler", "energy", 0)+AttrVal("Strom_Zaehler","overflowvalue",0)*AttrVal("Strom_Zaehler","overflow",0))/1000+AttrVal("Strom_Zaehler","offset",0))}
Das einzige was mir noch fehlt ist ein gute Weg "overflow" zu setzen wenn energy wieder überläuft.
Ich habe ein notify sobald ein energy Ereignis rein kommt, aber noch keinen einfachen Weg zu erkennen wann der Überlauf passiert.
die werte mit setreading zwischen speichern und auf "neu < alt" vergleichen.
Danke für den Tipp.
Habe es jetzt so gemacht. Mal gespannt ob das dann funktioniert wenn der nächste Überlauf ist.
Strom_Zaehler:energy.* {
my $oldenergy = ReadingsVal("Strom_Zaehler","state",0);
my $energy = ReadingsVal("Strom_Zaehler", "energy", 0);
if ($oldenergy > $energy)
{
my $overflow = AttrVal("Strom_Zaehler","overflow",0);
$overflow += 1;
fhem("attr Strom_Zaehler overflow $overflow");
}
fhem("setreading Strom_Zaehler state $energy");
}
ZitatMal gespannt ob das dann funktioniert wenn der nächste Überlauf ist.
wenn du dein energie reading nicht über readingsval fütterst, sondern mit der notify-variable $EVTPART1, kannst du den überlauf testen, indem du ein setreading energy xyz in die eingabezeile tippst. wobei xyz dann natürlich kleiner sein muss, als der letzte wert.
Hallo, nach dem ich seit gestern nun auch den Bausatz fertig habe und das Teil in Betrieb ist, stellt sich folgende Frage. Angeschlossen habe ich den mitgelieferten Gas Sensor, soweit so gut. Heute habe ich bemerkt, dass gasCnt immer aufsummiert wird und damit natürlich kein Tagesplot angelegt werden kann. Der Plot fängt um 00:00 Uhr ja mit dem Wert an der zuletzt in gasCnt steht und nicht bei 0 (wie es sein sollte). Habe schon einiges an User Readings und auch an sub Routinen ausprobiert das führt aber nicht zum erhofften Ergebniss. Habt ihr vlt. einen weiterführenden Tip?
Probiert habe ich den gasCnt Wert in einen dummy zu kopieren und um 23:59:59 auf 0 zu setzen.
P.S. der untere Plot fängt nicht bei 0 an, sollte für einen Tagesplot aber so sein
VG
Frank
du kannst delta-d im Feld function im Plot eintragen bzw. suchmal nach "delta-d" im Forum.
delta-h hab ich für das Balkendiagramm schon gesetzt, dass funktioniert auch wie es soll. Für den "echten" Tagesverbrauch hab ich jetzt schon eine Lösung mit 2 dummis und at gefunden. Ich schreibe gasCnt in einen dummy und setze diesen um 00:00:00 zurück, über setreading schreibe ich diesen Wert in die Sensor Readings. Somit startet der gasCnt jedesmal um 00:00:00 mit dem Wert 0 und zählt über den Tag dann hoch.
VG
Frank
Kann man da nicht was mit dem average-Modul machen? Das summiert doch auch tageweise die gezählte Werte auf, oder? Hab es jedoch noch nicht benutzt...
ZitatDas summiert doch auch tageweise die gezählte Werte
Das macht es, ABER du kannst nicht bei 0 starten also ab 24:00 Uhr mit dem Hochzählen neu starten, da gasCnt fortlaufend hochzählt und nicht tagweise.
Werde ich heute Nacht sehen ob mein Konstrukt das macht, was es soll ;)
P.S. average habe ich zum testen mal mitlaufen
VG
Frank
und das statisticsmodul?
Das statisticmodul sieht gut aus, da man den Startzeitpunkt auf z.B. 00:00 Uhr festlegen kann. Ich teste heute erst einmal meine sub.
VG
Frank
Schade, meine sub funktioniert natürlich nicht. Ich hätte berücksichtigen müssen, dass gasCnt ja weiterhin den Wert vom letzten Tag hat und nach dem Rücksetzen auf 0 (vom dummy) der alte Wert vom Vortag wieder in das dummy geschrieben wird.
VG
Frank
Ein Notify um 0:00 Uhr, dass die Differenz zwischen gasCnt und vorherigem Tag logged und danach den aktuellen gasCnt für den nächsten Tag merken. Bin noch nicht dazu gekommen, aber sollte eigentlich recht einfach gehen.
Da bin ich gerade auch drann 8)
Habe "nebenbei" nur noch einiges zu tun.
Statisticmodul geht für Gas nicht.
Zitataktuellen gasCnt für den nächsten Tag merken
Da hadert es noch drann.
VG
Frank
Warum geht das statistic-Modul für Gas nicht? Gefällt mir gerade richtig gut das Modul.
Hast du bei Gas nicht auch einfach ein Readings, das kontinuierlich wächst?
@vbs
Ich lass das Statisticsmodul jetzt mal laufen, die Readings sahen mir irgendwie seltsam für den Gasverbrauch aus.
P.S. Musste das state Format noch auf gasCnt anpassen, mal sehen ob es jetzt vernüftige Readings liefert
Das Modul kennt ja einige Reading-Namen von Haus aus (hard kodiert). Wahrscheinlich musst du dein "gasCnt" ihm erst bekannt machen. Ich habe bei mir alle vordefinierten Readings deaktiviert und dann nur die, die ich haben möchte festgelegt:
ignoreDefaultAssignments 1
deltaReadings energy
minAvgMaxReadings power
Ich denke, für dich wäre das deltaReading interessant. "energy" ist bei mir auch ein Zähler, der immer nur hochläuft.
Das Modul nimmt die Readings aus STATE, das hab ich jetzt auf gasCnt angepasst, somit bekommt das Modul nur das was ich brauche.
Hm, reden wir vom selben Modul?
Laut commandref, wird state nur für die Duration-Sachen genutzt, aber nicht für Delta:
Min|Avg|Max Minimum, average and maximum of instantaneous values:
over a period of day, month and year:
brightness, current, energy_current, humidity, temperature, voltage
over a period of hour, day, month and year:
wind, wind_speed, windSpeed
Tendency over 1h, 2h, 3h und 6h: pressure
Delta between start and end values - over a period of hour, day, month and year:
count, energy, energy_total, power, total, rain, rain_rate, rain_total
Duration (and counter) of the states (on, off, open, closed...) over a period of day, month and year:
lightsensor, lock, motion, Window, window, state (if no other reading is recognized)
Da hast du Recht, mann sollte nicht 10 Dinge auf einmal machen :)
Hab es jetzt mal laufen mit deltaReadings auf gasCnt.
So, das Modul scheint die erwünschten Ergebnisse zu liefern. Ein ReadingsVal gibt jetzt folgenden String zurück:
Hour: 0.00 Day: 1.35 Month: 1.35 Year: 1.35 (since: 2015-03-13_12:54:55 )
Fehlt nur noch ein Regex um die einzelnen Werte zurück zu bekommen. In der Art $sh = 0.00 $sD = 1.35 $ sM = 1.35 und $sY = 1.35
Ich hab im Moment sowas hier, um an Avg zu kommen (lässt sich sicherlich mit mittelgroßer Fantasie auch an deinen String anpassen):
#DbLog <SPEC1>:statPowerHourLast:::$val=~s/^Min..([\d.]*).Avg..([\d.]*)/$2/eg
Eingabe sieht bei mir so aus:
Min: 274 Avg: 396 Max: 2250
Joh, ist klar aber leider brauche ich die Werte einzeln und nicht nur für SVG sondern um sie mit setreading in einzelne dummys zu schreiben. Diese dummys brauche ich für meinen Lcars Floorplan und die Werte müssen in dummys stehen, damit ich sie über meine eigene css in der Schriftart, Schriftgröße und Farbe anpassen kann.
Mal sehen, hab mir gerade mal mein Perl Handbuch rausgesucht. Über split müsste da doch was zu machen sein.
VG
Frank
So, irgendwie komme ich nicht so richtig voran. Folgendes habe ich als sub:
In $gsp steht: Hour: 0.08 Day: 1.93 Month: 1.93 Year: 1.93 (since: 2015-03-13_12:54:55 )
sub Gas_split
{
my $gsp = ReadingsVal("Gas_Sensor","statGasCnt","0");
my @gsp = split /[:,\s\/]+/, $gsp;
foreach(@gsp) {
return "$_\n";
}
}
Leider wird die Schleife nicht abgearbeitet und als Resultat nur der erste Teil des ganzen Strings ausgegeben:
return :Hour
P.S. das wird jetzt langsam OT vlt. mach ich zu dem Thema einen neuen Thread auf
VG
Frank
foreach(@gsp) {
return "$_\n";
}
cool. beim ersten eintreten in die schleife kommt ein return - aus die maus. return braucht es nur einmal, dann ist schluss.
@ Martin
Jaaa, das das blöde return noch drinn stand hab ich ewig übersehen, zum testen sollte dort print stehen (Ausgabe im Log)
VG
Frank
@franky08
Kannst du mir mal die komplette Lösung zur Vereinzelung der Werte Stunde /Tag/ Monat/Jahr geben. Am liebsten wäre mir ein eigenes Reading für jedes.
Oder ein Tipp wo ich es villeicht nachlesen kann, wie es geht, wäre mir auch hilfreich.
VG Lutz
Edit: Danke hate sich erledigt! singularReadings <GerätRegExp:GeräteWertRegExp:Statistiktyp:Zeitraum>
Ich habe dafür eine sub die über at alle 5min aufgerufen wird:
sub Gas_split
{
my $gsp = ReadingsVal("Gas_Sensor","statGasCnt",0);
my @daten = split(/ /,$gsp);
my $h = $daten[1];
my $D = $daten[3];
my $M = $daten[5];
my $Y = $daten[7];
#return "Stunde: $h Tag: $D Monat: $M Jahr: $Y";
fhem "setreading Gas_split_dummy Gas_Stunde $h";
fhem "setreading Gas_split_dummy Gas_Tag $D";
fhem "setreading Gas_split_dummy Gas_Monat $M";
fhem "setreading Gas_split_dummy Gas_Jahr $Y";
my $gsp2 = ReadingsVal("Gas_Sensor","statGasCntLast",0);
my @daten2 = split(/ /,$gsp2);
my $hs = $daten2[1];
my $Ds = $daten2[3];
my $Ms = $daten2[5];
my $Ys = $daten2[7];
fhem "setreading Gas_Tage_Summe Gas_Stunde_summe $hs";
fhem "setreading Gas_Tage_Summe Gas_Tag_summe $Ds";
fhem "setreading Gas_Tage_Summe Gas_Monat_summe $Ms";
fhem "setreading Gas_Tage_Summe Gas_Jahr_summe $Ys";
my $gassum = ($M);
fhem "setreading Gas_Tage_Summe Gas_Tag_summiert $gassum";
}
VG
Frank