Homematic Wired - Homebrew Devices

[Bromm]

Hallo Markus!!

Danke für Deine Antwort! Ich hatte die letzten Tage leider keine Zeit mich weiter mit dem HBW-LC-Bl4 und HBW-Sen-SC8 zu beschäftigen. Das mit der register.h gucke ich mir nochmal an... Ich habe einen Original-1fach-Rolladen-Aktor, ich gucke mal bei Gelegenheit was der antwortet bei Level_Set, wenn Dir das weiterhilft. Bei dem HBW-LC-Bl4 habe ich ja auch noch das Problem, daß nur der erste Kanal reagiert und die anderen nicht und daß die Level nicht korrekt angezeigt werden.
Wenn ich den HBW-Sen-SC8 und auch den HBW-LC-Sw8 erfolgreich in Betrieb nehmen kann und die zugehörigen XML-Files laufen, dann bin ich auch schon einmal sehr zufrieden. Das löst ja schon einmal viele Grundaufgaben.

@ mago0211:

Hat eigentlich schon mal jemand ein Modul in ein Hutschienengehäuse eingebaut? Fände ich mal interessant wie so was aussehen könnte bin da immer wenig kreativ was Gehäuseeinbau betrifft.

Also, ich bin was das betrifft auch gerade an diesem Thema dran. Habe da auch schon recht konkrete Vorstellungen und bin grade dabei etwas zu entwickeln. Ein Modul für UP- sowie Hutschienen-Montage. Etwas das quasi universell einsetzbar und frei programmierbar ist. Auf Arduinobasis. Und eben mit dem Hauptaugenmerk auf praktischen bzw. kompatiblen Einbau in Standardeinbauorten wie UP-Dosen und Hutschiene... Weiteres folgt in näherer Zukunft, wenn es etwas spruchreifer ist... 

Viele Grüße
Björn

[MarkusO]

Hi Björn,

schau Dir mal die neue Version vom HBW-LC-Bl4 im Github an (https://github.com/kc-GitHub/HM485-Lib/tree/markus/HBW-LC-Bl4). Da ist das Problem, dass nur der erste Kanal funktioniert, gelöst. Wenn es damit noch immer Probleme gibt, kannst Du (und alle anderen natürlich auch) ein Issue im Github erstellen. Dann sind die Probleme gesammelt und können nicht im Forum irgendwie unter gehen.
Die anderen Modulen werde ich in den nächsten Tagen auch nochmal testen.

Mir ist auch aufgefallen, dass die Bezeichnung noch nicht so richtig gewählt ist. "SC" steht ja für Shutter contact, also einen Schließerkontakt bei Fenstern. Ich werde deshalb das Modul für die Taster in HBW-PB-12 umbenennen (und auf 12 Kanäle erweitern) und ein extra Modul für Fensterkontakte erstellen (HBW-Sen-SC12).

Wenn es da was neues gibt, stelle ich es direkt bei Github online.

Hat eigentlich schon mal jemand ein Modul in ein Hutschienengehäuse eingebaut? Fände ich mal interessant wie so was aussehen könnte bin da immer wenig kreativ was Gehäuseeinbau betrifft.

Für die Aktoren werde ich solche Gehäuse verwenden:
http://www.reichelt.de/CB-HUTKIT-9/3/index.html?&ACTION=3&LA=446&ARTICLE=133941&artnr=CB+HUTKIT+9
Da passt dann ein 8-fach Relaisboard zusammen mit einem kleinen HBW-Modul rein.

Viele Grüße
Markus

[Bromm]

Hi Markus!

Prima!! Danke! Ich werde es die Tage hoffentlich testen können... Ich gebe Dir Feedback!!
Freue mich auch auf die anderen überarbeiteten Module... Werde, so wie es mir die Zeit zulässt, dann auch hierfür die XMLs erstellen und testen.

Viele Grüße!!
Björn

[Bromm]

Hallo Markus!

Kleines Feedback: Ich habe nun nochmal den 4-fach-Rolladenaktor mit Deinen neuen Dateien getestet. Nun, es reagieren nun alle 4 Kanäle (bzw. alle 8 Relais), aber nicht wie erwartet. Es scheint immer noch Probleme mit dem Level zu geben. Die Fahrzeiten werden zwar wie in der CCU/LXCCU unter Einstellungen eingetragen ins EEPROM übertragen, doch beim Ausführen eine AUF oder ZU werden diese Zeiten nicht eingehalten. Fahrzeit vorgegeben zB 200 Sekunden (testweise), Relais ziehen aber nur ca. 3 Sekunden an.

Hier einmal ein Mitschnitt aus dem Terminal:

Code Auswählen Erweitern

State:al: 0
- Actual: 0
State: RELAY_OFF - Time: 10514760 - Target: 1 - Actual: 1
State: RELAY_OFF - Time: 10521171 - Target: 0 - Actual: 0
Huhu
Channel 0
TimeTopBottom: 2000
TimeBottomTop: 2000
TimeTurnAround: 15
Channel 1
TimeTopBottom: 1000
TimeBottomTop: 1000
TimeTurnAround: 15
Channel 2
TimeTopBottom: 2000
TimeBottomTop: 2000
TimeTurnAround: 15
Channel 3
TimeTopBottom: 2000
TimeBottomTop: 2000
TimeTurnAround: 15
Sending ACK or BroadcastF8
Sending
FF:FF:FF:FF:F8:00:06:5D:2C:12:41:00:82:00:03:06:48:42:57:30:34:31:37:30:36:38:82:C6:00:State: RELAY_OFF - Time: 1175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 1175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 1175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 1175 - Target: 0 - Actual: 0

Receiving
FD:00:06:5D:2C:18:00:00:00:01:05:78:00:02:BF:8C:parsing from loop...Requested Position: 1
Position unknown. Moving to reference position.

Sending
00:00:00:01:18:00:06:5D:2C:05:69:00:02:81:D2:00:
Receiving
FD:00:06:5D:2C:19:00:00:00:01:02:83:00:parsing from ackwait Received ACKState: WAIT - Time: 19038 - Target: 0 - Actual: 100
00:State: TURN_AROUND - Time: 19238 - Target: 0 - Actual: 100
State: MOVE - Time: 19239 - Target: 0 - Actual: 100
State: RELAY_OFF - Time: 21175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 21175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 21175 - Target: 0 - Actual: 0
Reference position reached. Actual position is known now
Sending ACK or BroadcastF8
Sending
FF:FF:FF:FF:F8:00:06:5D:2C:06:69:00:00:00:9A:0A:State: STOP - Time: 23631 - Target: 0 - Actual: 0
Reference position reached. Moving to target position now.
Requested Position: 1
00:State: WAIT - Time: 23740 - Target: 1 - Actual: 0
State: TURN_AROUND - Time: 23940 - Target: 1 - Actual: 0
State: MOVE - Time: 25440 - Target: 1 - Actual: 0
Sending ACK or BroadcastF8
Sending
FF:FF:FF:FF:F8:00:06:5D:2C:06:69:00:00:01:8A:08:State: STOP - Time: 27440 - Target: 1 - Actual: 1
00:State: RELAY_OFF - Time: 27640 - Target: 1 - Actual: 1

Receiving
FD:00:06:5D:2C:1A:00:00:00:01:05:78:00:02:33:B4:parsing from loop...Requested Position: 1

Sending
00:00:00:01:38:00:06:5D:2C:05:69:00:02:C2:42:00:
Receiving
FD:00:06:5D:2C:19:00:00:00:01:02:83:00:parsing from ackwait Received ACK00:
Receiving
FD:00:06:5D:2C:1C:00:00:00:01:05:78:00:00:97:FA:parsing from loop...Requested Position: 0

Sending
00:00:00:01:58:00:06:5D:2C:05:69:00:00:26:F6:00:
Receiving
FD:00:06:5D:2C:19:00:00:00:01:02:83:00:parsing from ackwait Received ACKState: WAIT - Time: 36945 - Target: 0 - Actual: 1
00:State: TURN_AROUND - Time: 37145 - Target: 0 - Actual: 1
State: MOVE - Time: 38645 - Target: 0 - Actual: 1
State: RELAY_OFF - Time: 41175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 41175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 41175 - Target: 0 - Actual: 0
Sending ACK or BroadcastF8
Sending
FF:FF:FF:FF:F8:00:06:5D:2C:06:69:00:00:00:9A:0A:State: STOP - Time: 41645 - Target: 0 - Actual: 0
00:State: RELAY_OFF - Time: 41845 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 61175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 61175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 61175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 61845 - Target: 0 - Actual: 0

Mit der Anzeige des Rollolevels in der CCU/LXCCU hakt es auch noch etwas. In der .pm-Datei habe ich unter Channel bei Conversion für Blind.level einen angegebenen Factor = 2 entdeckt und in der XML-Datei von ursprünglich 200 auf 2 angepasst.

Code Auswählen Erweitern

<parameter id="LEVEL" operations="read,write,event" control="BLIND.LEVEL"><logical type="float" default="0.0" min="0.0" max="1.0" unit="100%"/><physical type="integer" interface="command" value_id="LEVEL"><set request="LEVEL_SET"/><get request="LEVEL_GET" response="INFO_LEVEL"/><event frame="INFO_LEVEL"/></physical><conversion type="float_integer_scale" factor="2"/></parameter>

Scheint aber nicht die Ursache für das Problem gewesen zu sein... 

Was mir noch aufgefallen ist, ist daß es durch die verschiedenen Versionen der Libs für die Sketches der einzelnen Module zu Problemen innerhalb der Arduino IDE kommt. Sprich, eigentlich sollten ja HMWDebug.cpp/.h, HMWModule.cpp/.h und HMWRS485.cpp/.h für alle Sketches gleich sein, aber dies führt zu Problemen beim Kompilieren, da es hier scheinbar noch unterschiedliche Versionen gibt. Ebenfalls kann es hier dann auch zu Problemen mit der HMWRegister.h kommen. Daher verwalte ich nun also nur einen jeweiligen Homebrew-Aktor/Sensor einzeln in der Arduino IDE. Dann klappt es soweit. Nur zur Info, falls hiermit noch jemand Probleme haben sollte.

Gerne will ich auch noch den HBW-Sen-SC8 bzw. bald neu HBW-Sen-PB8/12 und HBW-LC-Sw8 ausprobieren, aber hierzu muß ich dann noch die XML bearbeiten bzw. erstellen.


Viele Grüße und einen schönen Abend!
Björn

[MarkusO]

Hallo Björn,

das Problem scheint relativ einfach zu sein. Zum besseren Verständnis, hier die Erklärung zur Debug-Ausgabe:

Code Auswählen Erweitern

Requested Position: 1
Die Sollposition ist 1, wobei 1 nicht auf oder zu bedeutet, sondern 1%. Das erklärt auch schon, warum der Aktor nur so kurz fährt. Ich denke, man müsste das XML bzw. pm-File irgendwie so anpassen, dass bei "zu" 100 als Sollwert geschickt wird und nicht 1.

Trotzdem hier noch die Erklärung des weiteren Ablaufs:

Code Auswählen Erweitern

State: WAIT - Time: 23740 - Target: 1 - Actual: 0
Das Relais für die Richtung wird geschaltet und 200ms gewartet, damit das Relais sicher geschaltet hat

Code Auswählen Erweitern

State: TURN_AROUND - Time: 23940 - Target: 1 - Actual: 0
Das "Ein/Aus"-Relais wird geschaltet. Der Raffstore fängt an sich zu drehen...

Code Auswählen Erweitern

State: MOVE - Time: 25440 - Target: 1 - Actual: 0
...und bewegt sich dann exakt 1500ms später in die entsprechende Richtung (1.5sek über das Webfrontend programmiert)

Code Auswählen Erweitern

State: STOP - Time: 27440 - Target: 1 - Actual: 1
Das "Ein/Aus"-Relais schaltet 2000ms später wieder ab. Die 2sek für 1% passen zu den 200sek, die über das Webfrontend für den kompletten Fahrweg programmiert wurden.

Code Auswählen Erweitern

State: RELAY_OFF - Time: 27640 - Target: 1 - Actual: 1
Damit das Richtungsrelais nicht permanent bestromt ist, wird es 200ms später abgeschaltet


Nach dem Einschalten des Moduls ist die Position des Rollos natürlich noch unbekannt. Bei der ersten Anforderung wird das Rollo daher für die maximale Fahrzeit angesteuert, um die Endlage sicher zu erreichen. Wenn die erste Sollposition nicht 0 oder 100 ist (wie in Deinem Fall), wird zunächst eine der Endlagen sicher angefahren, um eine Referenzposition zu haben und von dort aus dann erst die Zielposition angefahren. Also nicht irritieren lassen, das ist so gewollt 

Was mir noch aufgefallen ist, ist daß es durch die verschiedenen Versionen der Libs für die Sketches der einzelnen Module zu Problemen innerhalb der Arduino IDE kommt. Sprich, eigentlich sollten ja HMWDebug.cpp/.h, HMWModule.cpp/.h und HMWRS485.cpp/.h für alle Sketches gleich sein, aber dies führt zu Problemen beim Kompilieren, da es hier scheinbar noch unterschiedliche Versionen gibt. Ebenfalls kann es hier dann auch zu Problemen mit der HMWRegister.h kommen. Daher verwalte ich nun also nur einen jeweiligen Homebrew-Aktor/Sensor einzeln in der Arduino IDE. Dann klappt es soweit. Nur zur Info, falls hiermit noch jemand Probleme haben sollte.

So mache ich das mittlerweile auch. Habe es auch nicht geschafft, die Lib komplett gleich zu halten...

In der Datei 10_HM485.pm wird in Zeile 1667 nach der Bezeichnung "HMW_" geschaut:

Code: [Auswählen]

      $deviceName = ($model ne $modelType) ? $model . $deviceName : 'HMW_' . $model . $deviceName;

Mit der Bezeichnung HBW_LC_Bl4 habe ich dadurch immer Fehlermeldungen bekommen.
@Thorsten: hat das bei Dir mit dem 1-wire funktioniert? Ich habe gesehen, dass dort noch HBW_ in dem pm-File steht.

Seltsam. Bei mir hat das bisher immer funktioniert. Ich habe es jetzt aber auch für eine Weile nicht ausprobiert.
Was genau funktioniert denn nicht?

@Thorsten:
Der Name scheint tatsächlich nicht das Problem gewesen zu sein. Ich habe die folgende Fehlermeldung bekommen und daraus geschlossen, dass es mit den Namen zusammen hängt. Nach dem Ändern auf "HMW_" hat es keine Probleme mehr gegeben. Jetzt wollte ich den Fehler nochmal nachstellen, habe die Bezeichnung wieder zurück auf "HBW_" geändert aber die Fehlermeldung kommt nicht wieder... Seltsam, aber egal, Hauptsache es läuft jetzt.


Viele Grüße
Markus



Viele Grüße
Markus

[Thorsten Pferdekaemper]

Was mir noch aufgefallen ist, ist daß es durch die verschiedenen Versionen der Libs für die Sketches der einzelnen Module zu Problemen innerhalb der Arduino IDE kommt.

Das war eigentlich nie für die Arduino-IDE gedacht. Ich habe das von Anfang an mit Eclipse gebaut. Die Arduino-IDE finde ich für sowas ziemlich grausam, da man nur eine Stufe von Abhängigkeiten hat und nicht einmal zur Definition einer Funktion/Methode springen kann. Erstaunlich, dass man das trotzdem mit der IDE hinbekommen kann.

Sprich, eigentlich sollten ja HMWDebug.cpp/.h, HMWModule.cpp/.h und HMWRS485.cpp/.h für alle Sketches gleich sein, aber dies führt zu Problemen beim Kompilieren, da es hier scheinbar noch unterschiedliche Versionen gibt.

Da gibt es wahrscheinlich wirklich Unterschiede. Wenn ich wieder zuhause bin muss ich mich vielleicht mal dransetzen und das ganze analysieren. Vielleicht können wir die Versionen mal zusammenführen. Es kann dann aber gut sein, dass man alle Devices anpassen muss. Außerdem wird man die Callbacks entweder überladen müssen oder wir brauchen da etwas "generischere" Schnittstellen.

Ebenfalls kann es hier dann auch zu Problemen mit der HMWRegister.h kommen.

Ja, das ist noch so ein Punkt, wo es mit der Arduino-IDE schwierig wird. Ich verwende allerdings die HMWRegister.h nicht wirklich. (Oder?)

[Bromm]

Hallo Markus und Thorsten!

Vielen Dank für Euer Feedback!! Die Aufschlüsselung des Debugs ist auch sehr gut!! Hatte schon eine etwaige Vorstellung, was die Statusmeldungen betrifft, aber so ist es noch mal schön klar! Prima, Danke dafür!! Auch bei der 1 als Level war ich etwas stutzig, denn tatsächlich sieht man ja bei der Initialfahrt auch eine 100 stehen... Vielleicht liegt doch in folgender Code-Zeile der Hund begraben (so momentan auf der CCU/LXCCU):

<code>
<parameter id="LEVEL" operations="read,write,event" control="BLIND.LEVEL"><logical type="float" default="0.0" min="0.0" max="1.0" unit="100%"/><physical type="integer" interface="command" value_id="LEVEL"><set request="LEVEL_SET"/><get request="LEVEL_GET" response="INFO_LEVEL"/><event frame="INFO_LEVEL"/></physical><conversion type="float_integer_scale" factor="2"/></parameter>
</code>

Hier ist als maximaler Wert 1.0 angegeben. Mal sehen was passiert wenn ich den auf 100 setze. Dachte, hier ist mit 1.0 gleich 100% definiert. Ich bin leider zur Zeit nicht zu Hause, kann es daher nicht gleich testen...

Hier mal im Original-Code beispielsweise auf 100.0 gesetzt...:
<code>
<paramset type="VALUES" id="hmw_blind_ch_values">
            <parameter id="LEVEL" operations="read,write,event" control="BLIND.LEVEL">
               <logical type="float" default="0.0" min="0.0" max="100.0" unit="100%"/>
               <physical type="integer" interface="command" value_id="LEVEL">
                  <set request="LEVEL_SET"/>
                  <get request="LEVEL_GET" response="INFO_LEVEL"/>
                  <event frame="INFO_LEVEL"/>
               </physical>
               <conversion type="float_integer_scale" factor="200"/>
            </parameter>
</code>

Es wundert mich allerdings nur, da im Original-HM-1fach-Akor hier eine 1.0 im XML-File steht. Und im .pm-File für den 4-fach-Aktor ja auch eine 1.0.
Allerdings gibt es Unterschiede im conversion-Part: Im Original-HM-XML-File ist hier ein Wert von "200" eingetragen, wie oben zu sehen (<conversion type="float_integer_scale" factor="200"/>). Ich hatte ihn auf dem .pm-File basierend auf 2 geändert, wie noch eins weiter oben im Code zu sehen... Bin mir nicht sicher in wie fern sich das auswirkt... Testen kann ich ja leider erst zu Hause, aber mit "200" hatte ich, glaube ich mich zu entsinnen, auch die oben beschriebenen kurzen Fahrzeiten und bin erst bei der Fehlersuche auf diesen Unterschied gestoßen, weshalb ich hier auf "2" setzte...
Ansonsten sehe ich im Moment keine Stellen im XML- oder pm-File wo der Fehler herrühren könnte. Außer, daß es eventuell eine Stelle im Sketch gibt wo der Wert anders als erwartet empfangen wird? Sollte ja aber nicht der Fall sein... Komisch...

Hmm... Mit der Arduino IDE komme ich soweit recht gut zurecht... Aber Eclipse sieht auch interessant aus...

Viele Grüße!!
Björn

[Bromm]

Hallo Jungs!

Bin man wieder nach Hause gekommen und habe getestet...

Ich habe

Code Auswählen Erweitern

<logical type="float" default="0.0" min="0.0" max="1.0" unit="100%"/>
auf

Code Auswählen Erweitern

<logical type="float" default="0.0" min="0.0" max="100.0" unit="100%"/>
geändert und den conversion factor wieder auf 200 gesetzt:

Code Auswählen Erweitern

<conversion type="float_integer_scale" factor="200"/>

Nun werden die richtigen Prozente an den Aktor übermittelt und die Relais schalten wie gewünscht... Kleiner Ausschnitt:

Code Auswählen Erweitern

Receiving
FD:00:06:5D:2C:1E:00:00:00:01:05:78:00:C8:5A:4A:parsing from loop...Requested Position: 100

Sending
00:00:00:01:78:00:06:5D:2C:05:69:00:C8:24:EE:00:
Receiving
FD:00:06:5D:2C:19:00:00:00:01:02:83:00:parsing from ackwait Received ACKState: WAIT - Time: 718921 - Target: 100 - Actual: 50
00:State: TURN_AROUND - Time: 719121 - Target: 100 - Actual: 50
State: MOVE - Time: 720621 - Target: 100 - Actual: 50
State: RELAY_OFF - Time: 721175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 721175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 721175 - Target: 0 - Actual: 0
Sending ACK or BroadcastF8
Sending
FF:FF:FF:FF:F8:00:06:5D:2C:06:69:00:00:64:BA:CE:State: STOP - Time: 731621 - Target: 100 - Actual: 100
00:State: RELAY_OFF - Time: 731821 - Target: 100 - Actual: 100
State: RELAY_OFF - Time: 741175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 741175 - Target: 0 - Actual: 0
State: RELAY_OFF - Time: 741175 - Target: 0 - Actual: 0

Receiving
FD:00:06:5D:2C:18:00:00:00:01:05:78:00:96:6E:B6:parsing from loop...Requested Position: 75

Sending
00:00:00:01:18:00:06:5D:2C:05:69:00:96:50:E8:00:
Receiving
FD:00:06:5D:2C:19:00:00:00:01:02:83:00:parsing from ackwait Received ACKState: WAIT - Time: 751040 - Target: 75 - Actual: 100
00:State: TURN_AROUND - Time: 751240 - Target: 75 - Actual: 100
State: MOVE - Time: 752740 - Target: 75 - Actual: 100
Sending ACK or BroadcastF8
Sending
FF:FF:FF:FF:F8:00:06:5D:2C:06:69:00:00:4B:6A:94:State: STOP - Time: 757740 - Target: 75 - Actual: 75
00:State: RELAY_OFF - Time: 757940 - Target: 75 - Actual: 75


Aber leider werden die Level noch nicht korrekt zur Anzeige gebracht. Ändere ich den conversion factor zB auf "2" statt "200", dann werden zB 7500% statt 75% angezeigt. Aber das "Rollo" zeigt nicht den richtigen Stand an. Das ist quasi immer heruntergefahren und zeigt somit optisch 0% an. Woran das liegt? Eventuell liegt das irgendwie evtl am Sketch? Überträgt die CCU nicht normalerweise 1.0 für 100%? Was für Werte erwartet das Sketch? 100.0 für 100%? Irgendwo hier muß das Problem ja bestehen?
Auf jeden Fall lassen sich die Relais schon einmal wie gewünscht bedienen, aber es hapert nun noch an der korrekten Level-Anzeige in der CCU/LXCCU... Die kommende Woche werde ich leider zeitlich nicht zu weiterem kommen. Wollte das aber schon einmal als Feedback in den Raum werfen, vielleicht hat ja noch jemand eine Idee?

Viele Grüße!!
Björn


PS:
Nach Neustart erscheinen die aktuellen Level korrekt. Aber nach einer erneuten Bedienung ist immer 0% angezeigt und im Folgenden bleibt es dann auch bei der Anzeige von 0%. Auch wenn der Befehl mit dem entsprechenden Level korrekt am Aktor ausgeführt wird, so wird der rückgemeldete Level weiterhin bei 0% angezeigt...

[Thorsten Pferdekaemper]

Hi,
ich kann das momentan nicht mal schnell testen, aber ich glaube mich daran zu erinnern, dass die FHEM-Implementierung hier nicht kompatibel zu dem ist, was die CCU braucht.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
ich versuche mal was zu den Conversion Factors etc. zu sagen. Was von der CCU bzw. dem Device in der Nachricht übertragen werden sollte ist ein Wert zwischen 0 und 200. Die CCU mach dann daraus 0% bis 100%. Das steht auch so im XML (das ist vom Original-Dimmer oder Rollo-Aktor):

Code Auswählen Erweitern


   <frame id="LEVEL_SET" direction="to_device" type="#x" channel_field="10">
  <parameter type="integer" index="11.0" size="1.0" param="LEVEL"/>
</frame>
[...]
   <logical type="float" unit="100%" default="0.0" max="1.0" min="0.0"/>
[...]
   <conversion type="float_integer_scale" factor="200"/>

So funktioniert das auch bei meinen Experimenten.
Ich interpretiere das in etwa so: Der Befehl "LEVEL_SET" hat als Parameter einen integer-Wert der Größe 1. Anders gesagt 1 Byte. Was der Aktor dann wirklich daraus macht ist seine Sache. Weiter unten steht dann, dass der Wert als float aufgefasst wird mit der "Einheit" 100% (also nicht %, sondern 100%). Der Wert selbst bewegt sich zwischen 0 und 1, also mit Einheit zwischen 0% und 100%.
Die Konversion erfolgt per Multiplikation mit 200. Also 100% * 200 = 1.0 * 200 = 200.

Die FHEM-Implementierung scheint damit nicht so ganz umgehen zu können. Stattdessen braucht man im .pm-File so etwas:

"conversion" => {

"factor" => 2,

"type" => "float_integer_scale"

},

"logical" => {

"default" => 0,

        "max" => 100,

"min" => 0,

        "type" => "int",

"unit" => "%"

},

Mit float und der "Einheit" 100% funktioniert es in FHEM anscheinend nicht.
Gruß,
    Thorsten

[hglaser]

Hallo Thorsten , Hallo Björn

Leider hat gevoo in seiner Imlemetation sehr viele Gerätenamen "hardcodiert". Z.B. steht in der 00_HM485.pm in der sub HM485_Set:

Code Auswählen Erweitern

} elsif ( $cmd eq 'level') {
if ( uc( $deviceKey) eq 'HMW_LC_BL1_DR' or uc( $deviceKey) eq 'HMW_LC_DIM1L_DR') {
$value = $value / 100;
HM485::Util::logger( 'HM485_Set', 3, 'set ' . $name . ' level ' . $value);
}
Somit können die Homebrew Geräte nicht richtig funktionieren, da hier nur der 'HMW_LC_BL1_DR und HMW_LC_DIM1L_DR breücksichtigt wird und nicht in die spezifischen Device.pms nachgesehen wird. Mir hat das auch schon einiges an Kopfzerbrechen bereitet und den ganzen Schmarrn neugeschrieben.

Grüße Harald

[Thorsten Pferdekaemper]

Leider hat gevoo in seiner Imlemetation sehr viele Gerätenamen "hardcodiert". Z.B. steht in der 00_HM485.pm in der sub HM485_Set:

Ok, dann ist etwas verständlicher, dass die CCU mit unseren Kreationen oft kein Problem hat, aber FHEM schon.
Das sollte sich ändern...

[Bromm]

Hallo Zusammen!

Besten Dank für Eure Antworten!! Ich komme leider erst wohl übernächste Woche dazu hier aktiv weiter zu agieren... Aber das klingt zumindest als wäre es nicht unlösbar... Ich versuche es dann weiter den 4-fach-Aktor noch besser in die CCU/LXCCU zu integrieren bzw. das XML-File zu optimieren oder den Sketch vom Aktor anzupassen. Immerhin funktioniert der Aktor ja schon, wenn auch die Rückmeldung noch nicht korrekt in der CCU/LXCCU dargestellt wird.

Beste Grüße!!
Björn

[T.ihmann]

Also, ich bin was das betrifft auch gerade an diesem Thema dran. Habe da auch schon recht konkrete Vorstellungen und bin grade dabei etwas zu entwickeln. Ein Modul für UP- sowie Hutschienen-Montage. Etwas das quasi universell einsetzbar und frei programmierbar ist. Auf Arduinobasis. Und eben mit dem Hauptaugenmerk auf praktischen bzw. kompatiblen Einbau in Standardeinbauorten wie UP-Dosen und Hutschiene... Weiteres folgt in näherer Zukunft, wenn es etwas spruchreifer ist... 

Hallo Bromm,

das klingt ja interessant. Genau das, was ich fuer mein Neubauprojekt suche. Wenn Du naehere Infos hast, koenntest Du die hier posten. Wenn Du Unterstuetzung brauchst (Testen, etc.), kann ich gerne helfen. Arduino Vorkenntnisse sind vorhanden.

[Bromm]

Hallo T.ihmann!

Freue mich wenn es Interesse an dem Projekt gibt! Sowie ich es in einen spruchreifen Zustand bekommen habe, werde ich es hier vorstellen. Bei Bedarf komme ich gerne auf das Angbot zurück. Es gibt noch eine weitere Entwicklung, eventuell könnten auch beide Projekte zusammengefasst werden. Aus zeitlichen Gründen geht es bei mir erst in ca 2 Wochen weiter. Dann will ich die Entwicklung aber fokussiert vorantreiben, da ich selbst auch bald die Module verbauen will. Sie sollen mit den hier vorhandenen Homebrew Devices kompatibel sein. Natürlich sind sie es auf Grund der Arduinobasis auch für jedwede andere Projekte und eigene Entwicklungen... Ziel ist Einbaufähigkeit in Standardumgebungen wie UP und Hutschiene. Dabei möglichst alle Funktionen abdeckend und günstig im Preis. Weitere Details werden folgen.

Beste Grüße
Björn