Huhu. Thema 2 ist zumindest halb erledigt. … bissl doof ... hätte ich auch früher drauf kommen können xD

Durch RFLink konnte ich endlich die alte FHEM VM ausmachen. Dadurch dass die VM aus war ist die Kiste in den Energiesparmodus gewandert ... peinlich aber so isses

Thema mit dem nicht funktionierenden Neustart wenn das Modul dran ist bleibt allerdings. Komisch ... aber damit muss ich dann wohl erstmal leben.

Aber das Thema 1 bleibt unverändert und ist sehr nervig. Ich steuere knapp 30 Geräte (Rolladen und Licht) über das Ding. Die immer einmal manuell über den Objektbrowser schalten bevor es nach einem Neustart dann auch mit Nodered klappt ist doof -.-

Ggf. mach ich dann ein Startup Skript oder sowas.

Habe den RFLink nun seit 7 Tagen im Einsatz und mag das Teil ganz gerne.

Ich habe hier ein paar Sachen die mir aufgefallen sind … ggf. kann das ja wer bestätigen bzw. hat sogar eine Lösung dafür?

1: Nach einem Neustart von IOBroker / dem ganzen Host kann Nodered nicht den Objekten kommunizieren. Erst wenn ich über den Objektbaum manuell die Sachen geschaltet habe, funktioniert das Schalten über das Nodered Dashboard. Gibt es hier eine Lösung für?

2: Die zweite Sache ist relativ kritisch ... wenn ich den RFLink am PC (MacMini Late 2009 mit Windows 10 drauf) angeschlossen habe, fährt die Kiste nicht hoch. Zieh ich das Modul ab geht es. Zu 100% reproduzierbar.

Seit dem ich das Modul dran habe habe ich auch das Gefühl, dass das ganze System instabil geworden ist. Dies ist allerdings rein gefühlt und kann ich noch nicht belegen. Habe auf jeden Fall mehrere Abstürze gehabt (bei einem frisch [4 Wochen] aufgesetztem Win10). Auch aus dem nächtlichen IOBroker Neustart (wegen Vollbackup) klappt das neustarten des IOBroker Services nicht mehr.

Ich bin für jede Antwort dankbar.

Hi,

geiles Teil der RFLink .. ich glaube ich kann nun endlich mein FHEM abschalten.

Ein Thema habe ich allerdings noch … Gibt es eine Möglichkeit, dass Schaltevents die gleichzeitig reinkommen automatisch in einer Queue abgearbeitet werden mit einer Verzögerung? Aktuell ist es so, dass alle gleichzeitig ans Modul geschickt werden und meine 3-fach Aktoren das dann nicht checken.

Im Adapter habe ich eine solche Einstellung leider nicht gefunden.

Ah ok. Danke für die Info.

So oder so schon ziemlich geil. Der Rest kommt mit Sicherheit bei Zeit

Hi,

jemand ne Ahnung, ob ich Alexa über den Speak Command auch dazu bekomme zu flüstern oder ähnliches?

Theoretisch sollte das möglich sein.

https://developer.amazon.com/de/docs/cu … rence.html

Aber wie? xD

Jo.

Das einzig doofe ist halt der Punkt, dass man über IOBroker nicht auf "Auto" stellen kann.

Ansonsten funktioniert das alles top.

Ich mach die Konfig der Max Klamotten über die eigene Software von eq3. Also Wochenprofile, Pairing, Grouping etc.

Dann mach ich die Max Software aus und schmeiss den IOBroker Adapter an. Von da aus kann ich dann Steuern und auslesen.

Funktioniert so für mich wunderbar.

Die current Temp von den Thermostaten ist eh Grütze und für nichts valides zu gebrauchen.

So … Problem gelöst ... es lag tatsächlich an der VM. Obwohl die Kontrolle via Date korrekte Zeiten angezeigt hat war im Hintegrund alles defekt. Die VM hat alle paar Sekunden die Zeit neu synchronisiert und Offsets von mehreren Stunden gemacht.

Habe zum Testen noch 3 neue VMs gemacht. Debian: gleiche Fehlerbild. Rpi Image: ok. Win7: ok.

Habe jetzt erstmals alles auf den Windows Host portiert via IO Broker Fullbackup (was im übrigen wahnsinnig gut funktioniert) ... jetzt klappts auch ohne Probleme mit Kalender und scheduled Skripten.

Achtung an alle die auf alter Mac mini Hardware mit Windows Host eine Virtualbox mit einem Debian drin laufen haben :mrgreen:

Habe das nochmal durchgetestet. Weder JS noch Kalender triggern zuverlässig und korrekt. Selbst im Debugmodus bleibt das Log leer.

Ich bin sehr verwundert.

Habe aktuell aber leider keine Zeit um mehr in die Forensik zu gehen. Bei Gelegenheit teste ich nochmal weiter und gebe Bescheid.

Habe als Workaround Zeittrigger über Alexa gemacht. Da tun über den Cloudadapter zwar auch nur 9 von 10 Aufrufen … aber das liegt denke ich an der freien Version des Cloud Adapters. ... keine Ahnung.

Wo ich auf jeden Fall Themen hatte:

IO Broker läuft bei mir in einer VM in virtualbox. Ich hatte am Anfang große Themen mit der Zeit, weil die Zeitsynchro zwischen Host und VM nicht funktioniert hat. NTP wollte auch nicht. Das Erscheinungsbild war, dass die Zeit in der VM langsamer lief als korrekt. Nach einer Stunde hatte ich schon 15 Minuten Versatz. Das ist aber inzwischen korrigiert.

Ich teste mal den Kalenderadapter. Mal sehen ob der tut.