Hatte gestern Abend wieder das Phänomen.
Spiegelschranklicht war laut Konsole und Webfront an, in Wirklichkeit war es aber aus.
Anscheinend habe ich hier arge Probleme, was das Übermitteln von den Stati anbelangt.
Geschaltet wurde das Licht über den lokalen Taster, welcher am Shelly angeschlossen ist.
Es betrifft aber diverse Shellys und tritt seit Neuestem auf.
Da ich recht oft das Symcon 5.5 aktualisiere (Testing) scheint es mit einer der letzten Testing Versionen gekommen zu sein.
Ich kann auch beobachten, daß ich jedesmal nach einem Update der Testing einen Absturzbericht von IPS bekomme. Auch das ist erst seit der 5.5 so.
Kann mir da jemand helfen?
Das Problem mit den falschen Stati ist echt nervig
Den falschen Status habe ich nur wenn der Shelly per MQTT nicht erreichbar ist.
Entzerrt habe ich das Problem in dem ich einen zweiten Broker fpr die Shelly Duo angelegt habe.
21 Stück Shelly sind auf dem einen Broker und die Beleuchtungs-Dinger auf einem eigenen Broker.
Der IPS-Dienst hat sich zwei mal verabschiedet seit ich die Shelly`s habe. Bin aber mit dem Produktiv-System noch auf der 5.3. Auf dem Testsystem mit der 5.5 habe nur einen einzigen Shelly, so das das nicht aussagefähig ist.
Wenn der IPS-Dienst gestoppt wird und danach aktiviert wird sind einige Shelly`s per MQTT nicht mehr zu erreichen.
Danach kannst du die Dinger neu rebooten.
ist es möglich das Variablenprofil der Instanz manuell anzupassen? Beim RGBW2 hat der Gain das Profil ~Intensity.100 und der Weißwert ~Intensity.255. Ich würde das gerne angleichen.
Kann es auch sein, dass ich beim Colorpicker deshalb teils seltsame Ergebnisse erhalte?
habe aktuelles Modul (Beta Store) und habe aktuelles Modul geladen… dort finde ich den ‚shelly window‘ aber nicht den ‚shelly door window 2‘ der zusätzlich noch den tilt Winkel, die Temperatur und Vibration anzeigt.
Du könntest im MQTT Server den Debug zu öffnen (oder die Funktion zu aktivieren, sodass der Debug in die Datei geschrieben wird) Dort kannst du dann sehen, welche Pakete der Server empfangen hat. Oder wenn du zu 100% sicher sein willst, aktivierst du Wireshark und schaut dann, ob ein passendes Paket von deinem Gerät versendet wurde.
Wird der Zustande denn aktualisiert, wenn du es erneut schaltest? Sicher, dass das Gerät nicht ab und zu mal die Verbindung zum WLAN verliert in dem Moment, wo der Zustand übertragen werden sollte?
Heute morgen war es so das zB der Aktor real aus war, in der Konsole und demzufolge im WF jedoch ein.
Habe dann den Aktor direkt über dessen WebUI geschaltet (ein, aus), das änderte aber nichts an dem Zustand in IPS.
Habe dann den Aktor über das WF aus und eingeschaltet, seitdem läuft die MQTT Kommunikation wieder bzw nun ist es egal ob ich über das WF oder den Aktor direkt schalte, die Stati laufen wieder synchron.
Ich habe die Probleme definitiv erst seit der IPS 5.5, mit der 5.4 lief das alles ohne solche Vorfälle.
Bzgl WLAN: Das kann ich eigentlich ausschließen da unterschiedliche Aktoren betroffen sind (bisher nur bei Shelly Dimmer und Shelly2.5 beobachtet) und die WLAN Dämpfungswerte top sind.
Heute morgen war laut IPS das Wohnzimmerlicht an, in Wirklichkeit war es aber aus.
Habe dann den Debug des MQQT angeschmissen (mit Datei-Aufzeichnung), dann den Shelly Dimmer über das eigene WebUI eingeschaltet und kurz darauf wieder ausgeschaltet.
Kann ich Dir die Daten zur Verfügung stellen? Ich kann diese leider nicht auswerten. Habe mir die Uhrzeiten notiert, wo ich den Dimmer ein und ausgeschaltet habe.
Ich müsste dann nur wissen, welche Datei ich vom Raspi runterziehen muss bzw. wo ich die Debug Aufzeichnung finde?
Ich habe den Dump während dem Fehlerzustand (nicht den Moment wo es aufgetreten ist) und dann über den Zeitraum wo ich das Licht (welches laut IPS an war, in Wirklichkeit aus war) nochmals geschaltet habe.
Das Problem ist, das ich ja nicht rund um die Uhr zuhause bin und auch nicht nach jedem Schalten von Lampen auf das WF gucke. Mir fällt es meistens abends auf wenn ich zu Bett gehe und plötzlich sehe das ein Licht angeblich an ist, in Wirklichkeit aber aus ist.
Ich habe nun folgendes gemacht: Alle Dimmer (6 Stück) habe ich in einen separaten MQTT Server ausgelagert, die anderen 24 Shellys laufen auf einer anderen MQTT Instanz. Habe also 2 MQTT Instanzen am Laufen.
Kämpfe aber nach wie vor mit Latenzen beim Schalten (zB bei den Dimmern), obwohl nur 6 Geräte auf der MQTT Instanz laufen.
Du kannst es Dir auch gerne per Teamviewer mal anschauen wenn Du magst.
Ich kann das Verhalten nicht bestätigen bin allerdings noch auf der 5.3.
Bei mir entspricht der gesetzte Status mit dem Status im Webfront überein.
Seit die 21 Rollo Shellys auf einem internen Brocker und die Duo Shellys auf einem separaten internen Brocker laufen habe ich keine Probleme und der OPC aktiviert ist.
ich habe leider keine Teamviewer-Lizenz sonst hätte ich es mir schon mal angesehen.
Leider kann man nach der Umstellung von Teamviewer nur noch kurz auf einen Client schauen und die Verbindung wird dann getrennt.
Was hast du auf dem Pi für eine Prozessorauslastung? Bei mir ging es bei einer Prozessorauslastung von über 38% auf dem Pi 3B bei den Shelly`s nichts mehr.
Ich hätte gerne am Wochenende die IPS-Installation auf eine Pi4 umgestellt, aber leider musste ich auf meinem undichten Flachdach 150qm Kies „umschippen“, :mad:
Teamviewer ist doch für private Nutzung kostenlos und sollte eigentlich funktionieren?
Ich weiß jetzt auch nicht wie ich an die aktuelle CPU Auslastung komme oder wie ich das abfragen kann. Habe mal ein Skript gefunden, da sieht man zwar keine Auslastung aber die aktuelle Taktung und die aktuelle CPU Spannung. Die Taktung liegt soweit ich das sehe bei permanent 1400Mhz und die Spannung bei 1,2V herum.
Aber wie gesagt, das ist ein Skript was ich hier im Forum gefunden habe und zeigt nicht alle Werte an.
Habe noch ein anderes Skript gefunden. Dieses ermittelt auch die CPU Auslastung. Diese liegt so zwischen 92% - 99%. Das ist wohl ein bisschen viel??
Die CPU Temperatur liegt bei ca 53°C herum. Aber wie komme ich dem Verursacher nun auf die Schliche? Ein Neustart des Raspberry bringt zumindest keinen Erfolg…
Also wenn jemand Ahnung von der Materie hat (hohe CPU Auslastung) und bei mir mal schauen möchte oder kann, der darf sich gerne melden. Dann könnte man eine Remote Verbindung aufbauen.
