HMW-IO-12-FM falsche Kanäle

[mchott]

Hallo,

ich habe im ganzen Haus meiner Schalter per HMW-IO-12-FM angebunden. In der CCU2 wird dieser als solcher erkannt und ich kann auf die Ereignisse "PRESS_SHORT" und "PRESS_LONG" reagieren. Im iobroker wird dieser zwar ebenfalls als "HMW-IO-12-FM" erkannt, jedoch steht "STATE" zur Verfügung. Bei anderen IO-Modulen mit bspw. 4 Eingängen ist dies korrekt hinterlegt. Was kann man da tun?

[smiling_Jack]

Bin da vorgestern auf das selbe Problem bei mir gestoßen. Das muss eigentlich an der Definition in der io-packet.json liegen.Ich wollte da die nächsten tage mal nach kucken.

Habe auch noch große Probleme mit dem hmw 12/14 Analogausgänge sind da gar nicht möglich

Vielleicht schaff ich es am Wochenende :?

[Homoran]

…und wenn du dabei bist:

Auch die kanäle für die displayschalter (oled und epaper) werden nicht richtig zugeordnet/ interpretiert.

Wenn du da noch unterstüzung/Info brauchst sag bitte was und wie man daran kommt.

Gruß

Rainer

[smiling_Jack]

Hallo

ich habe gestern mal gekuckt und ich konnte mich sogar noch erinnern warum Hobbyquaker das damals bei ccu.io so gemacht hat.

Zur kleinen Erklärung. Die CCU1 ist sehr langsam und anfälling auf belastung

Darum wurden die Datenpunktbeschreibungen in CCU.IO hinterlegt.

Das Problem ist jetzt, das immer mal wieder neue Geräte kommen und das es Geräte giebt wo die Datenpunkte nicht eindeutig sind (so zb. beim HMW-IO-12-FM da kann ein Datenpunkt Eingang oder Ausgang sein)

Ich werde jetzt einbauen das man ein haken setzen kann das die Datenpunktbeschreibung immer von der CCU geholt wird. Das dauert bei mir mit Yahm auch nur 2-3 Sekunden. Bei einer CCU1 kann es auch mal Minuten dauern. Aber das ist nur einmalig, es muss ja auch nicht jeder machen und die Nutzung der CCU1 ist ja stark rückläufig.

Einwände ?

[Bluefox]

@smiling_Jack:

Hallo

ich habe gestern mal gekuckt und ich konnte mich sogar noch erinnern warum Hobbyquaker das damals bei ccu.io so gemacht hat.

Zur kleinen Erklärung. Die CCU1 ist sehr langsam und anfälling auf belastung

Darum wurden die Datenpunktbeschreibungen in CCU.IO hinterlegt.

Das Problem ist jetzt, das immer mal wieder neue Geräte kommen und das es Geräte giebt wo die Datenpunkte nicht eindeutig sind (so zb. beim HMW-IO-12-FM da kann ein Datenpunkt Eingang oder Ausgang sein)

Ich werde jetzt einbauen das man ein haken setzen kann das die Datenpunktbeschreibung immer von der CCU geholt wird. Das dauert bei mir mit Yahm auch nur 2-3 Sekunden. Bei einer CCU1 kann es auch mal Minuten dauern. Aber das ist nur einmalig, es muss ja auch nicht jeder machen und die Nutzung der CCU1 ist ja stark rückläufig.

Einwände ? `
Finde ich gut. Und defaultmässig true lassen.

[smiling_Jack]

@Bluefox:

Finde ich gut. Und defaultmässig true lassen. `

??? was soll Default mässig auf true ?

[Homoran]

Bin auch Bluefox' Meinung.

Standardmäßig konfig aus der CCU ziehen, CCU1 user können ja den Haken wegmachen.

Gruß

Rainer

[smiling_Jack]

@Homoran:

Bin auch Bluefox' Meinung.

Standardmäßig konfig aus der CCU ziehen, CCU1 user können ja den Haken wegmachen.

Gruß

Rainer `

ah ok, ja klar das kann ich machen

[mchott]

Das wäre ja super, wenn das klappt..ist das dann irgendwann drin oder wie bekomme ich das mit, dass sich genau das in einem Update verbirgt? Öfter mal pauschal reinsehen?

[smiling_Jack]

@mchott:

Das wäre ja super, wenn das klappt..ist das dann irgendwann drin oder wie bekomme ich das mit, dass sich genau das in einem Update verbirgt? Öfter mal pauschal reinsehen? `

Da sich beim hm-rpc Adapter im moment sonst nichts tut wird es wohl im nächsten update drin sein

[paul53]

@smiling_Jack:

Das Problem ist jetzt, das immer mal wieder neue Geräte kommen und das es Geräte giebt wo die Datenpunkte nicht eindeutig sind (so zb. beim HMW-IO-12-FM da kann ein Datenpunkt Eingang oder Ausgang sein)

Ich werde jetzt einbauen das man ein haken setzen kann das die Datenpunktbeschreibung immer von der CCU geholt wird. `
Mein Vorschlag: Die Datenpunktbeschreibung von den Geräten, für die keine Metadaten in der io-packet.json vorhanden sind, von der CCU holen.

EDIT: Sollte eigentlich schon enthalten sein (Datei hm-rpc.js, Zeile 802 ff.),

rpcClient.methodCall('getParamsetDescription', [obj.native.ADDRESS, 'VALUES'], function (err, res) {

scheint aber nicht zu funktionieren.

Erscheint nach Adapter-Neustart mit Haken bei "Synchronisiere Geräte neu (einmalig)" ein Info-Log, der den Text

"rpc -> getParamsetDescription" enthält ?

[Thisoft]

Hallo,

ich hänge mich mal hier mit dran da ich vermutlich das gleiche Problem habe.

Ich erhalte bei "Synchronisiere Geräte neu (einmalig)" folgendes Log:

! hm-rpc.0 2017-01-16 22:11:26.220 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["NEQ0358190:4","VALUES"] hm-rpc.0 2017-01-16 22:11:26.210 info hm-rpc.0 xmlrpc -> getParamsetDescription ["NEQ0358190:4","VALUES"] hm-rpc.0 2017-01-16 22:11:26.133 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["NEQ0358190:3","VALUES"] hm-rpc.0 2017-01-16 22:11:26.133 info hm-rpc.0 xmlrpc -> getParamsetDescription ["NEQ0358190:3","VALUES"] hm-rpc.0 2017-01-16 22:11:26.102 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["NEQ0358190:2","VALUES"] hm-rpc.0 2017-01-16 22:11:26.086 info hm-rpc.0 xmlrpc -> getParamsetDescription ["NEQ0358190:2","VALUES"] hm-rpc.0 2017-01-16 22:11:26.055 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["NEQ0358190:1","VALUES"] hm-rpc.0 2017-01-16 22:11:26.055 info hm-rpc.0 xmlrpc -> getParamsetDescription ["NEQ0358190:1","VALUES"] hm-rpc.0 2017-01-16 22:11:25.992 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["NEQ0358190:0","VALUES"] hm-rpc.0 2017-01-16 22:11:25.977 info hm-rpc.0 xmlrpc -> getParamsetDescription ["NEQ0358190:0","VALUES"] hm-rpc.0 2017-01-16 22:11:25.724 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["MEQ0690365:1","VALUES"] hm-rpc.0 2017-01-16 22:11:25.714 info hm-rpc.0 xmlrpc -> getParamsetDescription ["MEQ0690365:1","VALUES"] hm-rpc.0 2017-01-16 22:11:25.682 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["MEQ0690365:0","VALUES"] hm-rpc.0 2017-01-16 22:11:25.664 info hm-rpc.0 xmlrpc -> getParamsetDescription ["MEQ0690365:0","VALUES"] hm-rpc.0 2017-01-16 22:11:25.615 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["MEQ0197597:4","VALUES"] hm-rpc.0 2017-01-16 22:11:25.615 info hm-rpc.0 xmlrpc -> getParamsetDescription ["MEQ0197597:4","VALUES"] hm-rpc.0 2017-01-16 22:11:25.568 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["MEQ0197597:3","VALUES"] hm-rpc.0 2017-01-16 22:11:25.553 info hm-rpc.0 xmlrpc -> getParamsetDescription ["MEQ0197597:3","VALUES"] hm-rpc.0 2017-01-16 22:11:25.537 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["MEQ0197597:2","VALUES"] hm-rpc.0 2017-01-16 22:11:25.522 info hm-rpc.0 xmlrpc -> getParamsetDescription ["MEQ0197597:2","VALUES"] hm-rpc.0 2017-01-16 22:11:25.506 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["MEQ0197597:1","VALUES"] hm-rpc.0 2017-01-16 22:11:25.490 info hm-rpc.0 xmlrpc -> getParamsetDescription ["MEQ0197597:1","VALUES"] hm-rpc.0 2017-01-16 22:11:25.459 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["MEQ0197597:0","VALUES"] hm-rpc.0 2017-01-16 22:11:25.459 info hm-rpc.0 xmlrpc -> getParamsetDescription ["MEQ0197597:0","VALUES"] hm-rpc.0 2017-01-16 22:11:25.100 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["LEQ0411469:4","VALUES"] hm-rpc.0 2017-01-16 22:11:25.084 info hm-rpc.0 xmlrpc -> getParamsetDescription ["LEQ0411469:4","VALUES"] hm-rpc.0 2017-01-16 22:11:25.053 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["LEQ0411469:3","VALUES"] hm-rpc.0 2017-01-16 22:11:25.037 info hm-rpc.0 xmlrpc -> getParamsetDescription ["LEQ0411469:3","VALUES"] hm-rpc.0 2017-01-16 22:11:25.006 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["LEQ0411469:2","VALUES"] hm-rpc.0 2017-01-16 22:11:24.990 info hm-rpc.0 xmlrpc -> getParamsetDescription ["LEQ0411469:2","VALUES"] hm-rpc.0 2017-01-16 22:11:24.959 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["LEQ0411469:1","VALUES"] hm-rpc.0 2017-01-16 22:11:24.943 info hm-rpc.0 xmlrpc -> getParamsetDescription ["LEQ0411469:1","VALUES"] hm-rpc.0 2017-01-16 22:11:24.897 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["LEQ0411469:0","VALUES"] hm-rpc.0 2017-01-16 22:11:24.881 info hm-rpc.0 xmlrpc -> getParamsetDescription ["LEQ0411469:0","VALUES"] hm-rpc.0 2017-01-16 22:11:24.834 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["KEQ1054632:4","VALUES"] hm-rpc.0 2017-01-16 22:11:24.818 info hm-rpc.0 xmlrpc -> getParamsetDescription ["KEQ1054632:4","VALUES"] hm-rpc.0 2017-01-16 22:11:24.772 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["KEQ1054632:3","VALUES"] hm-rpc.0 2017-01-16 22:11:24.772 info hm-rpc.0 xmlrpc -> getParamsetDescription ["KEQ1054632:3","VALUES"] hm-rpc.0 2017-01-16 22:11:24.725 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["KEQ1054632:2","VALUES"] hm-rpc.0 2017-01-16 22:11:24.720 info hm-rpc.0 xmlrpc -> getParamsetDescription ["KEQ1054632:2","VALUES"] hm-rpc.0 2017-01-16 22:11:24.690 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["KEQ1054632:1","VALUES"] hm-rpc.0 2017-01-16 22:11:24.676 info hm-rpc.0 xmlrpc -> getParamsetDescription ["KEQ1054632:1","VALUES"] hm-rpc.0 2017-01-16 22:11:24.621 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["KEQ1054632:0","VALUES"] hm-rpc.0 2017-01-16 22:11:24.605 info hm-rpc.0 xmlrpc -> getParamsetDescription ["KEQ1054632:0","VALUES"] hm-rpc.0 2017-01-16 22:11:23.339 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["JEQ0657876:1","VALUES"] hm-rpc.0 2017-01-16 22:11:23.324 info hm-rpc.0 xmlrpc -> getParamsetDescription ["JEQ0657876:1","VALUES"] hm-rpc.0 2017-01-16 22:11:23.277 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["JEQ0657876:0","VALUES"] hm-rpc.0 2017-01-16 22:11:23.261 info hm-rpc.0 xmlrpc -> getParamsetDescription ["JEQ0657876:0","VALUES"] hm-rpc.0 2017-01-16 22:11:23.199 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["JEQ0536119:2","VALUES"] hm-rpc.0 2017-01-16 22:11:23.173 info hm-rpc.0 xmlrpc -> getParamsetDescription ["JEQ0536119:2","VALUES"] hm-rpc.0 2017-01-16 22:11:23.115 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["JEQ0536119:1","VALUES"] hm-rpc.0 2017-01-16 22:11:23.087 info hm-rpc.0 xmlrpc -> getParamsetDescription ["JEQ0536119:1","VALUES"] hm-rpc.0 2017-01-16 22:11:22.964 warn hm-rpc.0 xmlrpc <- undefined method getParamsetDescription ["JEQ0536119:0","VALUES"] hm-rpc.0 2017-01-16 22:11:22.933 info hm-rpc.0 xmlrpc -> getParamsetDescription ["JEQ0536119:0","VALUES"] !

wie ich auch in diesem Post http://forum.iobroker.net/viewtopic.php … 426#p31426 beschrieben habe.

Außerdem erhalte ich ständig die folgende Meldung:

hm-rpc.0 2017-01-16 22:17:32.294 warn hm-rpc.0 xmlrpc <- undefined method ping ["hm-rpc.0"] 

Was noch komisch ist: mit BIN-RPC geht gar nix, da verbindet sich der hm-rpc-Adapter noch nicht mal.

Gruß Thilo

[Homoran]

Hallo Thilo,

wie im anderen Thread vermute ich jetzt erst recht, dass dein HM-CFG-USB outdated ist und nicht das Mittel der Wahl für ioBroker ist.

Gruß

Rainer

[Thisoft]

Hmmm, irgendwie hatte ich zwar auch schon den Verdacht - wieso haben dann aber Andere wie paul53 oder mchott das gleiche Problem?

[Homoran]

Paul53 arbeitet mit hmcon. Ich weiss allerdings nicht ob er daran einen USB-Stick oder ein Gateway hat.

Ich hatte damals wohl als erster hm-con mit dem USB-Stick getestet und hobbyquaker hat das super ans Laufen bekommen.

Gruß

Rainer

[paul53]

@Thisoft:

…wieso haben dann aber Andere wie paul53 oder mchott das gleiche Problem? `
Das Problem habe ich nicht, da ich nur Geräte verwende, für die Metadaten vorliegen. Habe mich deshalb damit befasst, weil es offenbar ein Problem ist, das mehrere Nutzer von bestimmten Wired-Modulen betrifft.

@Homoran:

Paul53 arbeitet mit hmcon. Ich weiss allerdings nicht ob er daran einen USB-Stick oder ein Gateway hat. `
Ich verwende rfd (hmcon) für das Funkmodul HM-MOD-RPI-PCB.

[smiling_Jack]

@paul53:

@smiling_Jack:

Das Problem ist jetzt, das immer mal wieder neue Geräte kommen und das es Geräte giebt wo die Datenpunkte nicht eindeutig sind (so zb. beim HMW-IO-12-FM da kann ein Datenpunkt Eingang oder Ausgang sein)

Ich werde jetzt einbauen das man ein haken setzen kann das die Datenpunktbeschreibung immer von der CCU geholt wird. `
Mein Vorschlag: Die Datenpunktbeschreibung von den Geräten, für die keine Metadaten in der io-packet.json vorhanden sind, von der CCU holen.

EDIT: Sollte eigentlich schon enthalten sein (Datei hm-rpc.js, Zeile 802 ff.),

rpcClient.methodCall('getParamsetDescription', [obj.native.ADDRESS, 'VALUES'], function (err, res) {

scheint aber nicht zu funktionieren.

Erscheint nach Adapter-Neustart mit Haken bei "Synchronisiere Geräte neu (einmalig)" ein Info-Log, der den Text

"rpc -> getParamsetDescription" enthält ? `

Doch das geht und nur das Problem sind die Konfigurierbaren Datenpunkte und das man bei listDevice keinen eindeutigen Hinweis auf die Konfiguration bekommt

So muss man bei den Geräten sowiso immer alles von der CCU abrufen.

Ich habe das auch fast Fertig habe im moment nur nicht so viel Zeit

[Thisoft]

Es scheint ja zumindest so dass es mit diversen Nicht-CCU-Installationen Probleme gibt…

Ich habe deshalb mal meinen BidCos-Service komplett deinstalliert und dann nach diversen Reboots wieder installiert. Habe aber den gleichen Effekt wieder...

Naja, jetzt warte ich erst mal ob die Änderung von Smiling_Jack eine Besserung bringt.

[Homoran]

Tut sich hier noch etwas?

Auch die Kanäle beim HMW-IO-12-Sw14-DR werden alle als Tastereingänge interpretiert.

Gruß

Rainer

[DerGraf123]

Hänge mich auch noch mal dran.

HMW-IO-12-FM alles als Tastereingänge definiert.

Ich steuere derzeit die Kontroll-LEDs der Gira 6-fach Taster noch über die CCU2. Da ich jedoch einiges auf ioBroker umziehen möchte, ist der Fehler gerade aufgefallen.

Manuelle Betätigung des Ausgangs wird auch nicht in den Ereignissen angezeigt. Da kommt nix.

Habe testweise ein manuelles Objekt "STATE" erstellt. Hier bekomme ich dann die Fehlermeldung, dass der DP nicht existiert. Schade. Wäre am naheliegendsten gewesen

Wäre toll, wenn sich da noch was tut.

P.S. Die Ausgänge am 12/14 lassen sich mit ioBroker schalten.