UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[nieIP]

@nieIP:

Was mir schon mal auffällt … Symbole der Objekte sind ok, aber Namen werden nicht aus der CCU geholt. Unter rpc.1 stehen jedenfalls nur Seriennummern im Moment. `

Wenn man in Hm-rega den Haken bei HMIP aktiviert, werden auch Namen abgeholt :)

Das Leben kann so einfach sein :)

[Homoran]

@nieIP:

@nieIP:

Was mir schon mal auffällt … Symbole der Objekte sind ok, aber Namen werden nicht aus der CCU geholt. Unter rpc.1 stehen jedenfalls nur Seriennummern im Moment. `

Wenn man in Hm-rega den Haken bei HMIP aktiviert, werden auch Namen abgeholt :)

Das Leben kann so einfach sein :) `

Du wolltest doch immer so ein einfaches Leben haben ;-)

Gruß

Rainer

[nieIP]

@Jeeper.at:

Für die Namen musst du Im REGA Adapter den Haken bei IP setzen. Dann werden die Namen übernommen.

LG

Günther `

hatte ich grade schon selbst gefunden, danke.

Jetzt warte ich nur noch, ob Geräte gelöscht werden, oder doppelt angelegt werden.

bis später

PS dann können wir uns ja der Visualisierung der HMIP Heizungsgeräte in VIS noch mal widmen, da ging bisher gar nichts :)

[jens.maus]

@Jeeper.at:

ich habe vom letzten zu schnellen Updates noch ein paar Einträge in rpc.0 drinnen. Die gehören dort nicht hin.

Wie bekomme ich die wieder weg? Manuell löschen funktioniert nicht. `

Also bei mir hat das manuelle Löschen geklappt.

[nieIP]

Hallo

die Geräte werden bei mir nicht mehr gelöscht / neu angelegt. Somit bleibt auch die Konfig des History Adapters bestehen.

Wie eine Seite weiter vorn geschrieben, gibt es die HMIP Geräte bei mir auch noch mal unter rpc.0

Unter rpc.0 habe ich nur den Kanal 0 mit dem Datenpunkt Update_pending

Diesen Datenpunkt gibt es bei den HIP Geräten unter rpc.1 nicht.

Das wird wohl so richtig sein.

Geraten: Über das normale HM Protokoll wird ggf. ein Update der FW angestossen. deswegen der eine Datenpunkt im HM Protokoll.

Wie auch immer, es ist eine deutliche Verbesserung der Situation und HMIP kann endlich mit ioBroker genutzt werden.

[eric2905]

Moin zusammen,

ich habe heute früh das Update der beiden Adapter gemacht … und nun brennt die Luft ...

Ich schalte per Systemvariablen meine komplette Heizungsregelung.

Heute früh, nach dem Update (und reboot) habe ich eine Systemvariable für mein Gästezimmer umgestellt (dies bekomme ich per Pushover mitgeteilt). ==> Nachtrag: Pushover wird auf der CCU im Programm selber ausgelöst. Die SysVar-Änderung wurde also tatsächlcih auf der CCU ausgeführt.

Danach ging es los …

Die Pushover-Nachricht wechselte im 2-3 Sekundentakt (Sysvar false / true). Bei jedem Wechsel wird die Soll-Temp. im Gästezimmer angepasst ... DutyCylce (und was weiß ich noch) "geplatzt" ... Direktverknüpfungen und Programme reagieren nicht mehr.

Mittlerweile reagiert die CCU quasi kaum noch auf die WebUI (Meldung "BidCos-RF ... Eine Komponente der ... reagiert nicht mehr ...").

Habe jetzt die 3 Adapter-Instanzen (hm-rega.0, hm-rpc.0 und hm-rpc.1) gestoppt und hoffe, das die CCU sich fängt (ich komme per WebUI nicht mal mehr an die Systemwartung, um einen reboot durchzuführen).

Kann jemand dieses Verhalten bestätigen?

Gruß,

Eric

[apollon77]

Wenn der ioBroker was an die CCU sendet steht das bei "info" glaube ich in jedem Fall im Log (zumindestens bei normalen Kanälen, keine Ahnung ob auch per Systemvariablen) …

Du denkst also das der iobroker deine Systemvariable immer wieder auf einen anderen Wert setzt ... true auf false und zurück ?!

Gibt es denn Logik/Skripte die das machen?

[jens.maus]

@eric2905:

Kann jemand dieses Verhalten bestätigen? `

Also ich bezweifle mal einfach das es an den Anpassungen liegt die ich an den Adaptern vorgenommen habe um die Probleme die hier diskutiert worden sind zu lösen. Das hört sich meiner Meinung nach nach etwas anderem an und steht ggf. nur zufällig in zeitlichem Zusammenhang mit deinem update der Adapter.

[eric2905]

Hallo zusammen,

@apollon77:

Du denkst also das der iobroker deine Systemvariable immer wieder auf einen anderen Wert setzt … true auf false und zurück ?!

Gibt es denn Logik/Skripte die das machen? `
es sieht zumindest so aus, als ob es jetzt diesen Blinker-Effekt gibt.

Ich nutze die Art der Steuerung schon ewig und bis heute früh auch völlig ohne Probleme.

@jens.maus:

Also ich bezweifle mal einfach das es an den Anpassungen liegt die ich an den Adaptern vorgenommen habe um die Probleme die hier diskutiert worden sind zu lösen. Das hört sich meiner Meinung nach nach etwas anderem an und steht ggf. nur zufällig in zeitlichem Zusammenhang mit deinem update der Adapter. `
Ich habe ja auch nicht gesagt, dass es daran liegt. Ich habe nur den das Phänomen beschrieben, den zeitlichen Zusammenhang beschrieben und gefragt, ob es noch jemand hat - um eben auch die Adapter-Updates auszuschließen, wenn es sonst keiner hat.

Es hat nur die Updates der Adapter (4 Stück in Summe) gegeben und danach fing es an. Mehr wurde am System nicht verändert.

Das <u>warum</u> versuche ich ja gerade rauszukriegen.

Ich möchte nur ausschließen, das wir nun HMIP-Geräte nutzen können, aber dafür keine SVs mehr schalten können :lol:

Die CCU wurde vorhin mittels SSH-Zugriff rebootet (über WebUI ging da gar nichts mehr). Die 3 Adapter habe ich vorher im ioBroker deaktiviert.

Ich werde heute Abend, wenn ich wieder zu Hause bin, die 3 hm-Instanzen wieder aktivieren und dann sehen, ob was passiert.

Gruß,

Eric

[Homoran]

Hallo Eric,

Ich habe gestern auf einer meiner Installationen, genau gesagt auf der produktiven, alle updates gemacht.

Insgesamt laufen mindestens 4 ioBroker mit Verbindung zu YAHM (ich vergesse da hin und wieder schon mal einen, der im Eckchen vor sich hin brummt ;-) )

Ich habe bis jetzt nichts bemerkt, was problematisch sein könnte, YAHM läuft DC ist 0.

ioBroker log beim produktiven System zeigt nichts,

aber..

ich habe kein IP weder physikalisch vorhanden, noch in ioBroker konfiguriert!

Gruß

Rainer

[eric2905]

Entwarnung !!!

Habe alles in Ruhe durchgestartet und alles läuft wie am Schnürchen.

Keine Ahnung, was das Gesamtsystem da geritten hat …

Man macht das Update der hm*-Adapter und klickt 5 Minuten später in VIS auf einen Schiebeschalter, der auf der CCU eine SysVar von false auf true stellt. Nach 3 Sekunden geht der Schiebeschalter wieder in seine Off-Position und weitere 3 Sekunden später wieder in seine On-Position zu Wechseln, um weitere 3 Sekunden .... usw.

Jeder Wechsel wird mit einer Pushover-Nachricht bestätigt ... meine iOS-Geräte kamen kaum noch nach mit Popup-Meldungen, usw.

Und jeder Wechsel bedeutet eine Änderung der Soll-Temperatur einer Heizungsgruppe (in diesem Fall im Gästezimmer) über ein CCU-Program (welches auch die Pushover verschickt).

Bis ich das alles eingefangen hatte, war der DC auf 100% und alles hing.

Aber, wie gesagt, jetzt ist alles gut - es passt nur zeitlich wie Ar**h auf Eimer.

Gruß,

Eric

[mike2712]

Hallo,

das ist ja super mit dem HMIP Fortschritt,

neuerdings bekomme ständig folgende Fehlermeldung: hm-rpc.1 ist der HMIP Instanz, früher Cux Instanz, der Fehler is aber neu.

hm-rpc.1	2017-01-22 12:30:08.191	error	hm-rpc.1 init error: Error: connect ECONNREFUSED 192.168.178.20:2010

Weitere Meldungen hatte ich nachdem ich rpc.1 von CuX auf HMIP umgestellt hatte.

javascript.0	2017-01-22 12:30:00.048	warn	javascript.0 State "hm-rpc.1.CUX2801001.0.LOWBAT" not found
javascript.0	2017-01-22 12:30:00.048	warn	javascript.0 State "hm-rpc.1.CUX2801001.0.STICKY_UNREACH" not found
javascript.0	2017-01-22 12:30:00.048	warn	javascript.0 State "hm-rpc.1.CUX2801001.0.UNREACH" not found

Weiß jemand wo die Fehler herkommen ?

LG Mike

geändert: Code in Codetags gesetzt Homoran (Admin)

[Homoran]

@mike2712:

Weiß jemand wo die Fehler herkommen ? `
Wenn du uns noch sagst was sich hinter der IP verbirgt?

Gruß

Rainer

[mike2712]

Oh, ja das ist die Homematic CCU

[Homoran]

@mike2712:

Oh, ja das ist die Homematic CCU `
Hast du da die Firewall konfiguriert?

@mike2712:

Weitere Meldungen hatte ich nachdem ich rpc.1 von CuX auf HMIP umgestellt hatte. `
Da verwendet ein Skript wohl noch CuxD-Datenpunkte :(

Hinterher weiss man es immer besser, aber warum hast du denn keine weitere rpc-Instanz für HM-IP angelegt?

Gruß

Rainer

[mike2712]

@Homoran:

Hast du da die Firewall konfiguriert?

@mike2712:

Weitere Meldungen hatte ich nachdem ich rpc.1 von CuX auf HMIP umgestellt hatte. `
Hinterher weiss man es immer besser, aber warum hast du denn keine weitere rpc-Instanz für HM-IP angelegt?

Gruß

Rainer `

Firewall, hab da geschaut, und auf Vollzugriff geändert, jetzt habe ich *.1 wieder zur CuxD gemacht und *.2 für HMIP neu angelegt, wollte System nicht zu stark belasten und wusste selbst nicht mehr warum ich überhaupt CuxD hatte :-(.

hm-rpc.2	2017-01-22 13:09:48.345	error	hm-rpc.2 init error: Error: connect ECONNREFUSED 192.168.178.20:2010
hm-rpc.2	2017-01-22 13:09:18.346	error	hm-rpc.2 init error: Error: connect ECONNREFUSED 192.168.178.20:2010
hm-rpc.2	2017-01-22 13:08:48.347	error	hm-rpc.2 init error: Error: connect ECONNREFUSED 192.168.178.20:2010

Leider sind die Fehler immer noch da.

Lg Mike

[nieIP]

Hallo

kannst Du mal einen Screenshot von den Einstellungen des HMIP rpc Adapters hier rein stellen ?

[mike2712]

@nieIP:

Hallo

kannst Du mal einen Screenshot von den Einstellungen des HMIP rpc Adapters hier rein stellen ? `

ja

Jetzt bekomme ich den gar nicht mehr am laufen, bleibt gelb in der Übersicht.

Alles neu gestartet, jetzt scheint es zu gehen, ohne das ich was weiteres geändert habe.

[Homoran]

@mike2712:

Alles neu gestartet, jetzt scheint es zu gehen, ohne das ich was weiteres geändert habe. `
Reboot tut gut :mrgreen:

Gruß

Rainer

[nieIP]

Hallo

in Deinem Screenshot ist der Adapterport "0"

das hatte ich Anfangs auch. Die Empfehlung war, dort etwas über 20000 einzutragen.

Bei mir derzeit 22010

bei meinem rpc.0 rpc-bin ist als Adapterport 22001 eingetragen.

Das hat nichts mit den Porte Richtung CCU zu tun, da hat nur jemand "ähnliche" Nummern gewählt :)