@quotschmacher sagte in Test ViessmannAPI v2.0.0:

ich greife das mal auf: das sollte ja dann eigentlich zum einschalten über bewegungsmelder so laufen, das ich in viessmannapi.0.2050879.0.features.heating.dhw.pumps.circulation.schedule.commands.setSchedule.setValue bei auslösung des bewegungsmelders einen zeitplan mit der aktuellen zeit + ne stunde oder so eintrage und wenn keine bewegung mehr, dann einen leeren zeitplan. oder bin ich da jetzt ganz auf dem holzweg?

nochmal der vollständigkeithalber: zirkulationspumpe steuern geht soweit ganz gut (vitodens 200).

// schedule zum einschalten, allerdings nur zwischen 6 und 21 uhr
var pump_on = '{"mon":[{"start":"06:00","end":"21:00","mode":"on","position":0}],"tue":[{"start":"06:00","end":"21:00","mode":"on","position":0}],"wed":[{"start":"06:00","end":"21:00","mode":"on","position":0}],"thu":[{"start":"06:00","end":"21:00","mode":"on","position":0}],"fri":[{"start":"06:00","end":"21:00","mode":"on","position":0}],"sat":[{"start":"06:00","end":"21:00","mode":"on","position":0}],"sun":[{"start":"06:00","end":"21:00","mode":"on","position":0}]}'
// schedule leeren - pumpe ausschalten
var pump_off = '{"mon":[], "tue":[],"wed":[],"thu":[],"fri":[],"sat":[],"sun":[]}' 

setState("viessmannapi.0.xxx.features.heating.dhw.pumps.circulation.schedule.commands.setSchedule.setValue", JSON.parse(pump_on)); // oder pump_off

der vorteil das ganze über ein "begrenztes" schedule zu lösen: man muss bei der auswertung eines bewegungsmelders keine zeiten mehr auswerten. wenn der melder nach 21 triggert und das schedule neu gesetzt wird, startet die pumpe eh nicht.

ich hab gestern ganz wild die schedules hin und her geschaltet und es hat super funktioniert.

danke für den adapter @tombox

@freundernacht sieht aus wieder hier, oder: https://www.zigbee2mqtt.io/devices/TS0043.html
dann würde ich mal behaupten der ist kompatibel

@megawaldi oder halt einfach ne bool-variable mit rein die dann beim ersten durchlauf eben nicht gesetzt ist, log wird quasi ignoriert und dann wird die variable gesetzt und das log ausgewertet.

@idlebit ich habe ein gerät mit nem "bösen" friendly namen abgezogen, wurde nach einer weile als nicht mehr available angezeigt, angesteckt, ging wieder auf available. also verhalten wie gewünscht. vielen dank!

was mir noch aufgefallen ist: beim iobroker zigbee adapter, wurde das available "erneuert"/aktualisiert, wenn das gerät an den strom ging. solange ein gerät hier aber nicht als als nicht-available gelistet wurde, wird available nicht erneut aktualisiert. ich vermute aber mal, das liegt eher an zigbee2mqtt und desse availability-handling.

@peterfido ja - das war es tatsächlich. wobei die bei beiden instanzen auf 127.0.0.1 stand. beide instanzen laufen im docker container. bei der einen geht es, bei der anderen nicht... habe jetzt die korrekte ip eingetragen und es läuft. danke!!

Moin!

Ich habe bereits mein Raspberrymatic in meinen ioBroker integriert. Nun wollte ich das Ganze aber in eine zweite ioBroker Instanz bringen - also zweiten iobroker-Benutzer auf der Raspberrymatic aneglegt, auf der zweiten Instanz genau die selben Einstellungen wie bei der ersten gemacht und siehe da: es funktioniert nicht wirklich...
Hier mal ein Beispiel aus der funktionierenden Instanz:

Und hier der entsprechende Sensor aus der nicht funktionierenden Instanz:

Irgendwas fehlt da... Wie gesagt: ich habe die Settings zwischen beiden ioBroker-Instanzen mehrmals verglichen und sie sind für alle 3 Instanzen gleich und es gibt auch keine Fehler im Protokoll.

Hat spontan jemand eine Ahnung, woran es liegen könnte? Welche Infos soll ich noch nachreichen?

Ich danke schon mal!

@arteck ich schrieb ja nur, dass diese warnmeldung der grund war, warum ich längere zeit nicht geupdated hatte und dass das eine der änderungen von einer version die noch ging zu einer, bei der die instanz überhaupt nicht mehr startet war. irgendwas wurde ja an der websocket-kommunikation umgestellt. wobei das kein grund ist, nicht mehr zu starten. und mein log war halt auch leer -lediglich die SIGILL-meldung.

na das ist ja lustig... habe vor kurzem meine instanz seit langem mal geupdatet und dann startete sie auch nicht mehr. jetzt aufgrund dessen hier auf 2.10.1 zurück und es läuft wieder. ich hatte relativ lange mit dem update gewartet, weil da eine meldung war, das man ein neues auth-token brauchen würde. sowas nutze ich aber eh nicht.

@idlebit ich habe ein gerät mit nem "bösen" friendly namen abgezogen, wurde nach einer weile als nicht mehr available angezeigt, angesteckt, ging wieder auf available. also verhalten wie gewünscht. vielen dank!

was mir noch aufgefallen ist: beim iobroker zigbee adapter, wurde das available "erneuert"/aktualisiert, wenn das gerät an den strom ging. solange ein gerät hier aber nicht als als nicht-available gelistet wurde, wird available nicht erneut aktualisiert. ich vermute aber mal, das liegt eher an zigbee2mqtt und desse availability-handling.

@idlebit zeigt noch immer die selbe version an, aber sieht jetzt so aus, als würde es funktionieren - ich teste!

@idlebit sagte in Test Adapter zigbee2mqtt:

Wie zu sehen muss das Problem bei dir woanders liegen, da auch das markierte Device ohne Namen als offline angezeigt wird.

das device war tatsächlich stromlos. damit stimmt alles. wird korrekt als available angezeigt, wenn ich es bestrome.
habe gerade nochmal (mit der 2.4.2) getestet: /wohnzimmer/steckdosenleiste/sofa stromlos gemacht, bis von zigbee2mqtt als offline angezeigt, dann wieder bestromt und keine änderung im iobroker.

@paul53 das ist korrekt. die laufen ja aber auch nur, wenn das device offline ist. im idealfall laufen also 0 von 18 timeouts.

@paul53 aber mit javascript, wenn man vorher eine liste der zu triggernden device-ids anlegegt, dann ein dictionary mit timeouts, deren key der device id entspricht und dann auf die erste liste triggert, und dann mit der triggernden device-id auf das dict mit den timeouts zugreift.

@IdleBit sollte ja eigentlich das selbe tun, oder? ich kann auch gern mal auf nur json umstellen, kann mir aber nicht vorstellen, dass das was ändert, da es ja nur zusätzliche topics sind.

@quotschmacher sagte in Test Adapter zigbee2mqtt:

  output: attribute_and_json