OpenHAB: Lesen von 4Byte (13.013) von MDT Aktor liefert keine Werte

[saegefisch]

Hallo allerseits,

noch recht jung im Thema KNX und OpenHAB habe ich die letzten Nächte fasziniert mit besserem als Schlafen verbracht... OpenHAB kann wirklich begeistern!

Bevor ich die nächste Stufe "zünden" will und das Backend ob des - für mein Augen - lausigen Frontends mit dem optisch überragenden CometVisu ersetzt wird, quält mich aber ein wichtiges Problem:

Mein MDT Schaltaktor liefert mir für jeden Kanal wunschgemäß Energie (kWh) und Leistung (mA -> kW). Im Busmonitor sehe ich auch die richtigen Ausprägungen. Der Aktor schickt sie im unveränderlich als 4Byte im "13.013"-Format.

"00 00 00 05" -> 5kWh (im Busmonitor)
"0" (OpenHAB-Log)

Aber OpenHAB scheint 4Byte-Angaben auf keinem Weg verarbeiten zu können. Ich habe vieles versucht - erfolglos. Man sieht nur fehlerfrei eine Null im OpenHAB (im Log und im Frontend).
Es gibt ein paar Bug-Meldungen im Google-Bereich zu ähnlichen Themen, aber die haben nicht geholfen.

Hat jemand schon 4Byte-Werte bzw. die Energie-Messwerte des MDT Aktors in OpenHAB auslesen können?

Version: OpenHAB 1.4 Snapshot von Freitag

Danke und viele Grüße
Carsten

[teichsta]

Hi,

wie sieht denn konkret Deine *.item Konfiguration aus?

Bevor ich die nächste Stufe "zünden" will und das Backend ob des - für mein Augen - lausigen Frontends mit dem optisch überragenden CometVisu ersetzt wird

Vorsicht! Wer meckert wird gerne daran erinnert, es selber erstmal besser machen zu sollen ;-)

Gruß,

Thomas E.-E.

[saegefisch]

Hallo Thomas,

erst mal: Yepp, klare Entschuldigung, das war völlig undifferenziert und so nicht richtig; der Punkt geht klar an Dich. Danke für den Hinweis.
Die Classic ist schön einfach zu handhaben, ist aber dadurch in den Darstellungsmöglichkeiten recht begrenzt. Für den Einstieg ein schneller Erfolgsgarant. Je nach Anwendungsfall und optischen Vorlieben passt das oder nicht. Bei mir passte es nicht, da für mich "ein Objekt pro Zeile" im Layout nicht hilft - am Ende schafft es das nicht über meine persönliche und auch nicht über meine WAF-Hürde...

Anders gesagt: Danke an alle Mitwirkenden. openHAB ist genial im Wortsinn. Und die classic Oberfläche (+iOS-App) ist hilfreich und leicht zu handhaben. Mit CometVisu wird es auch sehr anspruchsvolle Anwender zufrieden stellen.

Zurück zum Thema: Der aktuelle Stand funktioniert fehlerfrei - aber leider ohne Ergebnis. Alle Versuche mit 9.001:, 12.001:, 13.001:, 14.001: oder 13.013 (entspricht meiner ETS-Einstellung) habe nichts gebracht.

/* - - - - -    M E S S W E R T E    - - - - - */  
/* Energie 13.013: */
Number MW_KG_Energie_WW_Umwaelzpumpe "Energie WW-Umwälzung [%d kWh]"     <energy> (KG_Hobby) { knx="+9/0/0" }
Number MW_KG_Energie_WW_Waermepumpe "Energie WW-WP [%d kWh]"             <energy> (KG_Hobby) { knx="+9/0/5" }
Number MW_KG_Energie_Sat_Server     "Energie SAT>IP-Server [%d kWh]"     <energy> (KG_Hobby) { knx="+9/0/20" }

Ausgabe:

Gruppenmonitor ETS:
--------------------
#    Zeit    Dienst    Flags     Prio    Quelladresse    Quelle    Zieladresse    Ziel    Rout    Typ    DPT    Info
3    2013-12-01 16:54:42.256    vom Bus        Low    1.1.2    1.1.2 WW,... AMI-1216.01 Schaltaktor mit Strommessung 12-fach    <Umbruch>
9/0/0    Energie WW-Umwälzpumpe    6    Antwort      13.013 Wirkarbeit (kWh)    00 00 00 05 | 5 kWh

openHAB:
------------------
...
16:53:55.298 INFO  runtime.busevents[:26] - Weather_Temperature state updated to 6
16:54:42.252 INFO  runtime.busevents[:26] - MW_KG_Energie_WW_Umwaelzpumpe state updated to 0.0
16:54:55.934 INFO  runtime.busevents[:26] - Weather_Wind state updated to 6.44
...

Viele Grüße,
Carsten

[teichsta]

Hi Carsten,

Bei mir passte es nicht, da für mich "ein Objekt pro Zeile" im Layout nicht hilft - am Ende schafft es das nicht über meine persönliche und auch nicht über meine WAF-Hürde...

die Argumentation lasse ich gelten :-)

Alle Versuche mit 9.001:, 12.001:, 13.001:, 14.001: oder 13.013 (entspricht meiner ETS-Einstellung) habe nichts gebracht.

mit "haben nichts gebracht" meinst Du, dass nur eine "0" sichtbar wird? Findest Du eventuell Einträge in der openhab.org? Wenn nicht, starte bitte mal mit "start_debug.xxx" und schaue mal, ob es dann relevante Logeinträge gibt.

Gruß,

Thomas E.-E.

[DirkE]

Hi Carsten,

zum Thema MDT kann ich leider noch nichts beitragen, dies könnte aber in Kürze auf mich zukommen. Ich fange gerade auf der anderen Seite an und versuche erst mal eine WAF kompatible Visu zu bastel. Bin auch am Thema CometVisu / openHAB dran, siehe dieser Thread.

Gruß
Dirk

[saegefisch]

Hallo Thomas,

ich hab' mal mehr mit geloggt, aber nichts gefunden, was auf ein Problem hindeutet. Rein technisch wird ja das Ticket wahrgenommen und erkennt - nur scheint es wegen des Formats nicht richtig interpretiert zu werden.

Neben der Energie in kWh als 4Byte liefert mir der Aktor auch die aktuelle Leistung in mA als "2Byte vorzeichenlos" im Format 7.001 bzw. genauer 7.012. Die werden ganz wunderbar interpretiert und angezeigt (siehe unten fett: die gemeldeten "0.79" bei Leistung, aber 0.0 bei Energie)

Daher sehe ich hier weder eine Konfigurationsproblem, noch ein Kommunikationsproblem...

Mit Debug-Aufruf im Event.log

...
2013-12-02 00:46:21 - [B]MW_KG_Energie_Sat_Server state updated to 0.0[/B]
2013-12-02 00:46:21 - [B]MW_KG_Energie_WW_Waermepumpe state updated to 0.0[/B]
2013-12-02 00:46:21 - [B]MW_KG_Energie_WW_Umwaelzpumpe state updated to 0.0[/B]
...
2013-12-02 00:48:32 - SD_KG_Sat_Server received command ON
2013-12-02 00:48:32 - SD_KG_Sat_Server state updated to ON
2013-12-02 00:49:05 - [B]MW_KG_Leistung_Sat_Server state updated to 0.79[/B]
2013-12-02 00:49:59 - SD_KG_Sat_Server received command OFF
2013-12-02 00:49:59 - SD_KG_Sat_Server state updated to OFF
2013-12-02 00:50:11 - MW_KG_Leistung_Sat_Server state updated to 0.0
...

und die vermutlich spannenden Teile aus openhab.log

...
00:38:46.775 DEBUG o.o.c.internal.CoreActivator[:170]- You are running 'v1.4.0' a potentially unstable version of openHAB. The current stable version is 'v1.3.1'.
00:38:46.775 DEBUG o.o.c.internal.CoreActivator[:126]- Created file 'C:\openhab\webapps\static\version' with content '1.4.0'
00:38:46.775 INFO  o.o.c.internal.CoreActivator[:72]- openHAB runtime has been started (v1.4.0).
...
00:39:05.261 INFO  o.a.cpr.AtmosphereFramework[:1491]- Auto detecting atmosphere handlers /WEB-INF/classes/
00:39:05.277 WARN  o.a.cpr.AtmosphereFramework[:1139]- Missing META-INF/atmosphere.xml but found the Jersey runtime. Starting Jersey
00:39:05.323 INFO  o.a.cpr.AtmosphereFramework[:427]- Installed AtmosphereHandler org.atmosphere.handler.ReflectorServletProcessor mapped to context-path: /*
...
00:39:05.791 INFO  o.a.cpr.AtmosphereFramework[:811]- Installing Default AtmosphereInterceptor
00:39:05.791 WARN  o.a.cpr.AtmosphereFramework[:696]- No BroadcasterCache configured. Broadcasted message between client reconnection will be LOST. It is recommended to configure the org.atmosphere.cache.UUIDBroadcasterCache
00:39:05.791 INFO  o.a.cpr.AtmosphereFramework[:704]- Broadcaster Polling Wait Time 100
...
00:39:11.563 DEBUG o.o.m.i.i.GenericItemProvider[:334]- Start processing binding configuration of Item 'MW_KG_Energie_WW_Umwaelzpumpe (Type=NumberItem, State=Uninitialized)' with 'KNXGenericBindingProvider' reader.
00:39:11.579 DEBUG o.o.m.i.i.GenericItemProvider[:334]- Start processing binding configuration of Item 'MW_KG_Energie_WW_Waermepumpe (Type=NumberItem, State=Uninitialized)' with 'KNXGenericBindingProvider' reader.
00:39:11.579 DEBUG o.o.m.i.i.GenericItemProvider[:334]- Start processing binding configuration of Item 'MW_KG_Energie_Sat_Server (Type=NumberItem, State=Uninitialized)' with 'KNXGenericBindingProvider' reader.
00:39:11.595 DEBUG o.o.m.i.i.GenericItemProvider[:334]- Start processing binding configuration of Item 'MW_KG_Leistung_WW_Umwaelzpumpe (Type=NumberItem, State=Uninitialized)' with 'KNXGenericBindingProvider' reader.
00:39:11.595 DEBUG o.o.m.i.i.GenericItemProvider[:334]- Start processing binding configuration of Item 'MW_KG_Leistung_WW_Waermepumpe (Type=NumberItem, State=Uninitialized)' with 'KNXGenericBindingProvider' reader.
00:39:11.610 DEBUG o.o.m.i.i.GenericItemProvider[:334]- Start processing binding configuration of Item 'MW_KG_Leistung_Sat_Server (Type=NumberItem, State=Uninitialized)' with 'KNXGenericBindingProvider' reader.

Es gibt neben INFO und DEBUG und WARN (s.o.) keine Fehlermeldungen.

@Dirk: Schon gesehen...verfolge ich schon ein paar Tage... tolle Unterstützung

Viele Grüße,
Carsten

[teichsta]

Hi,

mir ging es eher um einen Clean-Run (neues openhab.log) im Debug-Modus, wenn die 13.-er DPTs konfiguriert sind.

Gruß,

Thomas E.-E.

[saegefisch]

Hallo Thomas,

sorry, da habe ich Dich missverstanden. Natürlich kann ich damit dienen... Als Nutzer ist es das Mindeste, was ich tun kann, um die Entwicklung zu unterstützen.

Hier die Definition der Items:

/* - - - - -    M E S S W E R T E    - - - - - */  
/* Energie 13.013: */
Number MW_KG_Energie_WW_Umwaelzpumpe "Energie WW-Umwälzung [%d kWh]"     <energy> (KG_Hobby) { knx="13.013:+9/0/0" }
Number MW_KG_Energie_WW_Waermepumpe "Energie WW-WP [%d kWh]"             <energy> (KG_Hobby) { knx="13.013:+9/0/5" }
Number MW_KG_Energie_Sat_Server     "Energie SAT>IP-Server [%d kWh]"     <energy> (KG_Hobby) { knx="13.013:+9/0/20" }

/* Leistung 7.012:*/
Number MW_KG_Leistung_WW_Umwaelzpumpe "Leistung WW-Umwälzung [%d mA]"     <energy> (KG_Hobby) { knx="7.012:+9/0/1" }
Number MW_KG_Leistung_WW_Waermepumpe "Leistung WW-WP [%d mA]"             <energy> (KG_Hobby) { knx="7.012:+9/0/6" }
Number MW_KG_Leistung_Sat_Server     "Leistung SAT>IP-Server [%d mA]"     <energy> (KG_Hobby) { knx="7.012:+9/0/21" }

Und hier noch die Zeilen aus dem Gruppenmonitor:
# Zeit Dienst Flags Prio Quelladresse Quelle Zieladresse Ziel Rout Typ DPT Info
7 2013-12-02 22:17:43.036 vom Bus Low 1.1.2 1.1.2 WW,... AMI-1216.01 Schaltaktor mit Strommessung 12-fach 9/0/20 Energie SAT>IP-Server 6 Antwort 13.013 Wirkarbeit (kWh) 00 00 00 02 | 2 kWh
11 2013-12-02 22:18:35.483 vom Bus Low 1.1.2 1.1.2 WW,... AMI-1216.01 Schaltaktor mit Strommessung 12-fach 9/0/21 Leistung SAT>IP-Server 6 Schreiben 7.012 Strom (mA) 00 4F | 79 mA

Ich finde allerdings gar nichts zur Interpretation in den beiden Dateien. Gibt es noch andere Log-Dateien, die die Interpretation der DPT zeigen? Wo erfolgt überhaupt die Interpretation der DPT?

Danke für Deine Unterstützung!

Viele Grüße,
Carsten

[saegefisch]

Konnte mittlerweile schon jemand von einem MDT Schaltaktor die Energie-Messwerte - geliefert mit DPT 13.013 - in openHAB verarbeiten? Ich bin für jeden Tipp dankbar; am besten war ich nur zu blöd und die Lösung ist ganz einfach...
Die aktuellen Leistungswerte in mA sind hingegen wunderbar zu verarbeiten. Mit

<mapping name="mAzuW">
<formula>y = x/10*230;</formula>
</mapping>

bekommt man die Werte in W (z.B: im Format format="%.1f W"; MDT liefert in DPT 7.012) ausgegeben. Okay, zugegeben, mit der Formel liefert der MDT wohl nicht wirklich mA oder 7.012 macht da Unfug mit der Dezimalstelle. Egal, Werte sind so plausibel.
(Danke Chris M. für die simple und zugleich leistungsfähige formula-Lösung. Sehr fein! Siehe hier; in der Doku steht dazu noch nichts, aber im XSD. Da lohnt immer ein Blick hinein...)

Viele Grüße,
Carsten

Edit: Die Formel oben reicht natürlich nicht, da fehlt noch ein wenig cos phi-Logik. Am besten mit 2 cos phi, da der bei niedrigen Werten (Standby) meist erheblich anders aussieht, als im Betrieb der meisten technischen Geräte (PC, TV, WW-Wärmepumpe: ca. 0,8, im Standby ca. 0,1 - 0,3) Simple Glühlampen (ohmsche Last) haben hingegen eher 0,95. Zu LED-Strips/LED-GU10-Spots habe ich noch keine Meinung, muss ich mal messen. Da muss ich die Tage noch mal ran. Aber das ist OT, hier ging es erst mal ja nur um "Wert auslesbar und in Visu dargestellt")...

[ichprobiersaus]

Ich habe den gleichen MDT Aktor

Hallo,

ich habe das gleiche Problem und wunderte mich, dass kaum Werte ankommen.

items Datei

/* Sicherungen und Stromzaehler bei MDT nur Wh 13.010 verwenden kWh 13.013 sind ohne Nachkommastelle und ungenau - mA 7.012 geht in openhab kW 9.024 Gleitkomma geht nicht leider*/
Number Sicherung6_EG_Wohnzimmer_WH    "7-EG Wohnzimmer [%d Wh]"        (EG_Wohnzimmer, Sicherung) { knx="<13.010:2/1/7" }
Number Sicherung6_EG_Wohnzimmer_A    "7-EG Wohnzimmer [%d mA]"        (EG_Wohnzimmer, Sicherung) { knx="<7.012:2/1/6" }

openhab.log Datei zeigt mal einen eigenständigen Read-Request mit Update in rr4dj

15:15:02.158 DEBUG o.o.p.r.internal.RRD4jService[:121]- Stored 'Sicherung6_EG_Wohnzimmer_WH' with state '84870' in rrd4j database
15:15:02.216 TRACE o.o.c.p.i.PersistItemsJob[:56]- Storing item 'Sicherung6_EG_Wohnzimmer_WH' with persistence service 'rrd4j' took 58ms
15:16:02.078 DEBUG o.o.p.r.internal.RRD4jService[:121]- Stored 'Sicherung6_EG_Wohnzimmer_WH' with state '84870' in rrd4j database
15:16:02.136 TRACE o.o.c.p.i.PersistItemsJob[:56]- Storing item 'Sicherung6_EG_Wohnzimmer_WH' with persistence service 'rrd4j' took 58ms
15:17:02.008 DEBUG o.o.p.r.internal.RRD4jService[:121]- Stored 'Sicherung6_EG_Wohnzimmer_WH' with state '84870' in rrd4j database
15:17:02.086 TRACE o.o.c.p.i.PersistItemsJob[:56]- Storing item 'Sicherung6_EG_Wohnzimmer_WH' with persistence service 'rrd4j' took 78ms
15:18:02.129 DEBUG o.o.p.r.internal.RRD4jService[:121]- Stored 'Sicherung6_EG_Wohnzimmer_WH' with state '84870' in rrd4j database
15:18:02.206 TRACE o.o.c.p.i.PersistItemsJob[:56]- Storing item 'Sicherung6_EG_Wohnzimmer_WH' with persistence service 'rrd4j' took 78ms
15:18:07.686 DEBUG o.o.b.k.i.bus.KNXBinding[:425]- Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH
15:19:02.148 DEBUG o.o.p.r.internal.RRD4jService[:121]- Stored 'Sicherung6_EG_Wohnzimmer_WH' with state '85410' in rrd4j database
15:19:02.206 TRACE o.o.c.p.i.PersistItemsJob[:56]- Storing item 'Sicherung6_EG_Wohnzimmer_WH' with persistence service 'rrd4j' took 58ms

openhab.log Datei aktualisiert regelmässig wenn ich alle 15 Minuten in mysql schreibe. Dann wird auch ein aktuellerer Wert in die rrd4j geschrieben

16:02:02.068 DEBUG o.o.p.r.internal.RRD4jService[:121]- Stored 'Sicherung6_EG_Wohnzimmer_WH' with state '85450' in rrd4j database
16:02:02.126 TRACE o.o.c.p.i.PersistItemsJob[:56]- Storing item 'Sicherung6_EG_Wohnzimmer_WH' with persistence service 'rrd4j' took 58ms
16:03:01.978 DEBUG o.o.p.r.internal.RRD4jService[:121]- Stored 'Sicherung6_EG_Wohnzimmer_WH' with state '85450' in rrd4j database
16:03:02.056 TRACE o.o.c.p.i.PersistItemsJob[:56]- Storing item 'Sicherung6_EG_Wohnzimmer_WH' with persistence service 'rrd4j' took 78ms
16:03:46.008 DEBUG o.o.p.m.i.MysqlPersistenceService[:304]- mySQL: Stored item 'Sicherung6_EG_Wohnzimmer_WH' as '85590'[85590] in SQL database at Thu Mar 06 16:03:46 GMT 2014.
16:04:01.979 DEBUG o.o.p.r.internal.RRD4jService[:121]- Stored 'Sicherung6_EG_Wohnzimmer_WH' with state '85590' in rrd4j database
16:04:02.037 TRACE o.o.c.p.i.PersistItemsJob[:56]- Storing item 'Sicherung6_EG_Wohnzimmer_WH' with persistence service 'rrd4j' took 59ms
16:05:02.148 DEBUG o.o.p.r.internal.RRD4jService[:121]- Stored 'Sicherung6_EG_Wohnzimmer_WH' with state '85590' in rrd4j database
16:05:02.226 TRACE o.o.c.p.i.PersistItemsJob[:56]- Storing item 'Sicherung6_EG_Wohnzimmer_WH' with persistence service 'rrd4j' took 78ms
16

[/share/HDA_DATA/.qpkg/openhab/logs] # grep 'Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH' openhab.log
16:29:05.279 DEBUG o.o.b.k.i.bus.KNXBinding[:425]- Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH
17:31:13.194 DEBUG o.o.b.k.i.bus.KNXBinding[:425]- Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH
17:33:16.584 DEBUG o.o.b.k.i.bus.KNXBinding[:425]- Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH
17:35:21.914 DEBUG o.o.b.k.i.bus.KNXBinding[:425]- Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH
10:35:43.857 DEBUG o.o.b.k.i.bus.KNXBinding[:425]- Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH
10:37:35.357 DEBUG o.o.b.k.i.bus.KNXBinding[:425]- Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH
10:47:40.417 DEBUG o.o.b.k.i.bus.KNXBinding[:425]- Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH
10:49:44.238 DEBUG o.o.b.k.i.bus.KNXBinding[:425]- Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH
10:59:47.477 DEBUG o.o.b.k.i.bus.KNXBinding[:425]- Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH
11:36:02.369 DEBUG o.o.b.k.i.bus.KNXBinding[:425]- Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH
11:37:54.609 DEBUG o.o.b.k.i.bus.KNXBinding[:425]- Sending read request to KNX for item Sicherung6_EG_Wohnzimmer_WH

Irgendwie sendet openhab read requests ohne erkennbare Systematik. Komisch.

Als Workaround versuche ich gerade in der ETS einzustellen, dass der MDT den aktuellen Wert alle 10 Minuten auf den Bus schreibt.

Ich kämpfe gerade damit einen täglichen Verbrauch zu berechnen ...

[saegefisch]

Hallo ichprobiersaus,

tatsächlich war die Verbrauchsmessung für mich durchaus einer der wesentlichsten Punkte bei der KNXisierung meines bisher konventionell verkabelten Hauses. Daher war ich recht unglücklich, dass ich aus dem MDT-Aktor zwar die Leistung (in mA) heraus bekommen habe, nicht aber die vom Gerät aufsummierte Energie (in Wh). Die DPT waren nicht zum laufen zu bringen.

Leider habe ich zu meinem (und nun auch Deinem) Problem keinen Fortschritt bei OpenHab gesehen. Hinzu kam, dass die Visu bei mir immer mal wieder nicht verlässlich auffrischte und unspezifisch hängen blieb. Darüber hinaus war es für mich (und viel mehr für meine Frau -> WAF) wichtig, in der Visu Universalzeitschaltuhren setzen und löschen zu können mit ein paar Finger-Klick. In OH und in den meisten anderen Lösungen, die ich mir anschaute, geht das nur durch Programmierung in der Config. So flexibel das auch sein mag: für mich keine Option, denn nach 1 Monat weiß ich schon nicht mehr, wie das geht.

Möglicherweise gibt es mittlerweile neue Versionen, die diese Punkte im OH und CV gelöst haben, aber ich habe mich zwischenzeitlich für den gira HS entschieden und habe es noch nicht bereut - wenn auch vergleichsweise fürstlich bezahlt. Die Visu funktioniert in meiner Wahrnehmung von der 1. Sekunde verlässlich ohne Ausnahme, die Schaltuhren sind ein Traum, die Logik-Engine ist find' ich (für mich) noch besser, als die schon sehr ordentliche im OH. Selbs mit der "Mädchen-Visu" QuadClient sieht die Strommessung sehr gut aus...und funktioniert von der 1. Sekunde. Dafür hat der HS andere Macken.

Mit meinem anfänglichen Engagement für OH und CV habe ich dem Thema (in diversen Beiträgen) denk ich eine gute Chance gegeben und trauere keiner Sekunde davon nach. Es war cool und spannend. OH ist eine wirklich tolle Lösung und kombiniert mit CV auch sehr schön (meine subjektive Meinung). Zusammen mit diesem tollen Forum und dem herausragenden Fortschritt des Entwicklerteams ist und bleibt OH mit CV eine Top-Lösung. Erst recht auf dem cubieboard mit 2,5Watt - unschlagbar in Leistung/W!

Für meine Ansprüche (ich habe eigentlich wenig Zeit zum Tüfteln - auch wenn ich für mein Leben gerne tüftle) und meiner kurzen Toleranzschwelle zum "wieso hängten die Visu schon wieder" war es dennoch die richtige Entscheidung in den HS zu investieren. Wie Du siehst, schaue ich aber dennoch immer mal wieder im OH und CV-Forum vorbei (trotz meiner knappen Zeit), weil ich das Projekt toll finde und es mich noch immer fasziniert.

Nun hoffe ich, dass sich im OH noch jemand Deinem DPT-Thema annimmt. Die MDT-Schaltaktoren mit Strommessung sind zu gut (für Ihren Preis), als dass sie nicht im OH unterstützt werden sollten!
Da es im HS gut funktioniert, werde ich selbst noch weitere 24 Kanäle über MDT schalt und messbar machen.

Viele Grüße,
Carsten

[ichprobiersaus]

Danke für Die superschnelle Antwort

Ja ich bin auch zeitlich eher knapp bestückt. Hatte bisher folgende Programme verwendet:

2 Tage openremote - ist schlecht unterstützt finde ich

seit Wochen - Android KNX Controller (funktioniert super und ganz Easy zu programmieren), geht aber nur zum schalten und Dimmen. Keine Serverfunktionen

Seit einer Woche openhab - ist viel besser als openremote. Im Prinzip gehen auch alle Sachen, auch die Diagramme etc. Man muss nur wahnsinnig viel rumprobieren, was sehr viel Zeit kostet. Wenn man was neues ausprobiert dauert es Tage bis es dann endlich gut läuft.

Was kostet denn so ein Homeserver und ... kann man ihn selbst programmieren und auch ggfls Plugwise oder andere Dinge mit einbinden ? Wenn ja wäre das vielleicht auch was für mich, falls ich in den nächsten Wochen mit openhab nicht voll zurecht kommen.

Danke und Grüsse
Michael

[saegefisch]

Hi,

das ist jetzt aber ziemlich OT...

<OT>
ab 1.800€. Aber ich bin zufrieden und wenn ich meine Zeit bewerte, ist das (für meine Bewertung) schnell relativiert. Ich nutze nicht die "freie Visu" (in Foren auch "Männer-Visu" genannt: Toolunterstützt, aber alle Freiheiten), sondern die von gira beworbene "Quad"-Visu (QC; in Foren die "Mädchen-Visu"). Sieht gut aus, nach nur einer Nacht tüfteln ging alles inkl. Diagrammen, Stromverbräuchen, etc. Sogar einfache Logik z.B. für meine WW-Umwälzpumpe war schnell im grafischen Logik-Editor ebenso schnell wie im OH (per Script) gemacht. Schnelles Ergebnis - genau wie gewünscht! QC ist damit für mich genau richtig.

QC schränkt einen aber auch ein durch die gebotenen PlugIns und Vorlagen. Ist ein wenig wie Apple: Alles was geht, geht super schnell und einfach. Aber "ausbrechen" aus den Grenzen ist aufwändiger. Wer will, kann sich alles selber um eigene ergänzen (z.B. Anbindung FritzBox hat jemand freundlicherweise programmieren lassen und bereitgestellt hier im Forum). Aber mein Ansatz war: Schnell zu einem hinreichenden und ansehnlichem Ergebnis und funktional verlässlich. Das hat geklappt. Sogar das umlegen von Timern macht meine Frau und ich ohne Einweisung. Jederzeit simpel auf dem ipad direkt in der visu.
Im OH hat das alles bei mir(!) länger gedauert, aber natürlich habe ich beim HS von den OH-Erfahrungen viel partizipiert. Daher ist der Vergleich hier nicht ganz stimmig.

Fazit: Teuer. Gut. Effizient. Für mich richtig, für andere sicher nicht.

Ach ja: Alles geht mit dem HS: Sehr leistungsfähig. Aber besondere Lösungen sind in jeder Lösung besonders - und damit aufwändig. Die Standardsachen fand ich schön simpel. Wenn man sich mal "rein gedacht" hat - ist halt konzeptionell völlig anders als OH.

</OT>

Aber zurück zum Thema: Was ist zu tun, damit im OH die Verarbeitung von 4Byte-Werten (13.013) erfolgreich funktioniert. Hat jemand eine Lösung parat?

Carsten

[nilseckert]

Hallo,

ich habe den selben Aktor und verwende den DPT 13.010 Wirkarbeit (Wh) anstatt 13.012 Wirkarbeit (kWh).

Da ist die Genauigkeit halt auch noch etwas größer und der Wertebereich sollte mit 2^31 - 1 = 2147483647 Wh = 2147483,647 kWh = 2147,5 MW auch lange reichen ;-)

Number Stromzaehler_KWL				"Lüftung (Wirkarbeit) [%d Wh]"				<icon>	(Stromwert, Stromzaehler)	{ knx="<13.010:2/3/44" }

Das Problem scheint eh zu sein, dass man mal Wh, und mal kWh braucht. Vielleicht kann man ja mit einer einfachen Regel beim Change-Event von dem Item den kWh Typ errechnen und dann ein zweites Item über OpenHAB setzen.

[ichprobiersaus]

Berechnung mit 13.013 (wh -&gt; kwh)

Ja, das mit der Umrechnung habe ich auch schon versucht über eine Regel zu implementieren ... war aber noch nicht erfolgreich.

Meine items Datei. Ich habe das neue Item Number Sicherung7_EG_Kueche_kWH angelegt, das über eine Regel gefüllt werden soll.

/* Sicherungen und Stromzaehler bei MDT nur Wh 13.010 verwenden kWh 13.013 sind ohne Nachkommastelle und ungenau - mA 7.012 geht in openhab kW 9.024 Gleitkomma geht nicht leider*/
Number Sicherung7_EG_Kueche_WH    "7-EG Kueche Kuehlschrank [%d Wh]"    (EG_Kueche, Sicherung){ knx="<13.010:2/1/3" }
Number Sicherung7_EG_Kueche_kWH    "7-EG Kueche Kuehlschrank Test[%d kWh]"    (EG_Kueche, Sicherung)
Number Sicherung7_EG_Kueche_A    "7-EG Kueche Kuehlschrank [%d mA]"        (EG_Kueche, Sicherung){ knx="<7.012:2/1/2" }

Hier die Regeldatei

import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*
import java.lang.Math
import java.util.Calendar
import java.util.Date
import java.util.TimeZone
import java.text.SimpleDateFormat

rule "Sicherung7 in kWH"
when
    Item Sicherung7_EG_Kueche_WH changed or System started
then
            var Number value_wh
            var Number value_kwh
            if (Sicherung7_EG_Kueche_WH.state instanceof DecimalType) 
            {
                value_wh = Sicherung7_EG_Kueche_WH.state as DecimalType
                value_kwh = (Math::round(value_wh.floatValue/1000))
                Sicherung7_EG_Kueche_kWH.postUpdate(value_kwh)
                logDebug("Sicherung7 Rule Execution" + value_wh + "wh " + value_kwh + "kwh")
            }
end

Funktioniert leider nicht ...

20:10:42.300 DEBUG o.o.m.r.i.engine.RuleEngine[:285]- Executing rule 'Sicherung7 in kWH'
20:10:42.342 ERROR o.o.c.s.ScriptExecutionThread[:50]- Error during the execution of rule 'Sicherung7 in kWH': Index: 1, Size: 1

Aus der Fehlermeldung werde ich auch nicht so recht schlau.

Bisher habe ich noch keine Persistence eingebaut. Na ich muss halt mal weiter probieren .... vielleicht hat auch jemand eine schlaue Idee :-)