Zu der Zeit, kein Zugriff über ein Gerät auf homee.
Node Red habe ich nicht und die Backup Datei liegt bei einer Größe von 425kb.
Okay das klingt erstmal gut, daran kann es also wirklich nicht liegen. Dann hoffe ich das die @homee‘s eine Lösung für dein Problem finden.
Der Verlauf der Zigbee und Enocean Geräte zeigen keine Auffälligkeiten.
Schade das kein homee dieses hier kommentiert hat.
Dann wäre das ja eine wichtige Funktion:
immerhin hat thomas ihm ein like gegeben…
Hey @HighControl Thomas
Das kann doch langsam nicht mehr sein.
Hat keiner mal ne Minute Zeit dir zu helfen von @homee Team oder @Tobias .
Das ist verdammt schade.
Ich drücke dir weiterhin die Daumen.
VG
Also, an der Stelle muss ich wirklich mal ins Horn stoßen.
Liebe Devs, lasst ein altgedientes, stehts hilfsbereites Mitglied der Community nicht in den Seilen hängen. Helft @HighControl bitte zeitnah, denn das steht gut zu Gesicht und macht 'n schlanken Fuß.
@homee, @Tobias, @Timo, @Thomas, @anon97065019 - wer auch immer. Ran an die Waffen!
Moin,
ich bin ja ganz eurer Meinung, aber warum seit Ihr so überrascht?
@Micha, wie lange hast Du damals auf Hilfe gehofft? Hast Du überhaupt welche bekommen?
Machst Du die Selber oder startet homee neu durch?
Viele Grüße
JayJay
Eigentlich ich, außer gestern, da hat homee das übernommen und ich musste selbst nicht ran ^^.
Es scheint immer zu passieren, wenn ich drei WallPlug schalte. Habe diese drei Wallplug schon abgelernt und neue angelernt. Leider ohne Erfolg. Ich werde jetzt noch einmal Verzögerungen einbinden…
Stimmt da war was .
Und gelöst wurde das Problem bis heute nicht.
Habe es selber gelöst , in dem ich 4 Geräte in die Tonne geworfen habe.
hmmm momentan spinnt der Homee in der Tat etwas arg… so kann auch von hier auf jetzt nicht mehr jedes Gerät der CCU “angesprochen” werden - sprich man setzt z.B. die Temperatur eines Wandthermostates auf einen Wert x - Homee sagt auch, er hätte das geändert…aber es ändert sich nix auf der CCU…
startet man dann den Homee neu, so rennt das wieder wie gewohnt…
“Momentan” ist die Untertreibung des Jahres
Leider lief mein System von Anfang an nicht einmal wirklich problemlos. Aktuell:
- HGs werden nicht so gespeichert wie ich sie einstelle
- Z-Wave Dimmer die ich per HG gemeinsam schalte, haben von Lampe zu Lampe 10s Pause
… um mal die übelsten Probleme zu nennen.
Interessant. Bei mir ist seit der 2.16 Z-Wave unglaublich stabil - dafür ist die ZigBee-Reichweite jetzt deutlich geringer, die Hälfte meiner ZigBee-Geräte ist immer grau… In den Versionen vor 2.16.2 (2.16.0 - 2.16.1) sogar alle
Das kann ich bestätigen, Zigbee devices schalten nicht obwohl scheinbar erreichbar oder sind (seit 2.16 nicht erreichbar (was sie vorher waren).
Auch die Esszimmerlampe (2 teilig) schaltet das “untere Teil” zuverlässig und das “obere Teil” fällt manchmal aus. Dann geht die obere Lampe einfach nicht aus auf Alexa Kommando. Schaltet man den Strom weg mit dem Schalter und schaltet wieder ein, geht das obere Teil wieder eine Zeit lang.
Aber noch bin ich an der z-wave Baustelle. Da sind übrigens ne Menge Fibaro Bewegungsmelder die auch nicht mehr zuverlässig funktionieren. Ob es an den Bewegunsgsensoren liegt oder daran das die Zigbee Lampen nicht geschaltet werden kann ich nicht so genau sagen. Ist mal so mal so - jedenfalls total unzuverlässig und WAF Faktor bedingt bin ich kurz davor das ich meine Pläne über den Haufen werfen muss und mir was neues suchen :-/
LG Tom
Kurzes Feedback: @Tobi1 war heut auf dem homee von @HighControl drauf.
→ siehe hier
Der Fehler liegt nicht im Z-Wave Stack, sondern im RAM der volläuft. Daher klagte HighControl neben Z-Wave Problemen auch über EnOcean Probleme.
HighControl hat noch eine V1 des BrainCubes, wir werden mal schauen wie sich ein V2 bei Ihm verhält und dann weiter auf die Suche gehen was den RAM so volllaufen lässt.
Das könnten Homeegramme mit Verzögerungen sein, die mehrfach getriggert viele Instanzen ausführen, aber auch die Verlaufsdatenbank wird Ihren Teil dazu tun.
Wir kennen jetzt also das Problem aber noch nicht die Ursache.
Da war ich wohl SEHR voreilig mit meiner Beschuldigung.
Dafür möchte ich mich an dieser Stelle, bei @Tobias und dem Team entschuldigen.
Entschuldigung
@Tobias DDDAAAANNNKKKEEE für Deine Hilfe!
Wie groß ist denn deine Installation?
Geräte?
homeegramme?
Wenn ich eine Wall Plug schalte zur bestimmten Uhrzeit 12:00 per homeegramm EINSCHALTEN
Und wenn ich um 12:05 ein weiteres Homeegramm habe das dies AUSSCHALTET.
Dann funktioniert das wunderbar und absolut zuvrlässig.
Wenn ich die AUSSCHALTEN homeegramme lösche und statt dessen beim EINSCHALTEN sage, einschalten und in 5 Minuten AUSCHALTEN (über Zeit gesteuert) funktioniert das absolut unzuverlässig.
Warum?
Ich hab ein Gefühl, ich glaub in den zeitgesteuerten Dingen ist ein Bug. Das betrifft auch Bewegungsensoren die das Licht ausmachen sollen bei nicht Bewegung und mal halt einfach nicht. Also, Lampe wird einschaltet wegen Bewegung und soll nach xx Minuten (im selben homeegramm ausschalten) ist praktisch sehr unzuverlässig. Mit eigenem homeegramm ausschalten geht wunderbar (nur leider nicht brauchbar in den meisten Szenarien). Ist das nur bei mir so? Gibt es einen Trick?
LG Tom
Poste mal bitte ein Screenshot von deinem Homeegramm.
Ich hatte (Asche auf mein Haupt) vor kurzem auch Disko in der Küche und dachte es liegt am Z-Wave Netzwerk. Bis sich Thomas meine Homeegramme angesehen hatte. Vor allem jene mit Prüfzeitpunkten und zeitlicher Verzögerung waren schuld. Hat man mehrere Aktionen und den Prüfzeitpunkt auf: “Prüfen bei Ausführen der Aktion” - so wird das Homeegramm nicht einfach abgebrochen, nur weil bei der ersten Aktion die Bedingungen nicht zutreffen. Das Homeegramm läuft weiter. Wird es durch andere Geräte, wie beispielsweise Motion Sensoren getriggert, so werden mehrere Instanzen des Homeegramm gestartet (Homeegramm läuft mehrfach).
Das führt dann schnell zum wilden ein- und ausschalten von von Lichtern oder ähnlichem
Was ich damit sagen will: Prüft vor allem bei Homeegrammen mit zeitlichen Verzögerungen die Logik und setzt im Zweifel lieber eine Bedingung mehr - welche die Szene besser beschreibt, als zu wenig. Denn auch das kann dazu führen, das Kommandos blind in das Netzwerk gesendet werden und erhöht damit den Netzwerktraffic enorm.