Hallo Stefan, das wichtigste Anliegen zuerst: 1000 Dank für all’ Deine Beiträge zum Thema HomeMatic! Ich kann nicht genug betonen, wie viele Ideen und Lösungen durch Dich den Weg zu meinem Erfolg in diesem Bereich gefunden haben und übernommen wurden - bitte weiter so! Dir könnte ich stundenlang zuhören. Zu Deinem Workaround möchte ich anmerken, dass es eine schwierige Aufgabe wurde, deine Anweisung dieses Beitrags umzusetzen. Einerseits weil Du oft nur kurz im KZread Video die Links zur Software einblendest, andererseits weil zwischenzeitlich manches veraltet ist. Aber es sind noch genügend Infos im Beitrag vorhanden, um vom Kauf des Stick (Link) bis hin zum flashen des selben und Installation der Software auf dem PC alles nachzuvollziehen. So habe ich wegen DutyCycle-Überlauf auch die Tipps dieses Beitrags abgearbeitet. Ergebnis der Mühe: meine HomeMatic versucht seit einem Monat 25 Updates für Fensterkontakte und 2 Updates für Fussbodenheizungssteuerung gleichzeitig zu installieren. Einmal gestartet kann man es nicht mehr rückgängig machen. Was als erstes in der AskSinAnalyserXS aufgefallen ist, der wesentliche Anteil der Meldungen sind Relay-Daten an Steckdosen, welche ich als Router und Relay angemeldet hatte. Stets zwischen 80 und 99% Duty Cycle über alles. Nach Rücksprache mit dem technischen Support von ELV kristallisierte sich als Lösung die Einbindung eines zusätzlichen Access Points heraus. Dieser läuft seit heute Mittag zusammen mit der CCU3 und nun sind 50% der Duty Cycles auf dem Zusatzgerät. Mein Problem ist über Umwege damit gelöst. Insgesamt aber ein Erfolg Deiner informativen, technischen Ausarbeitungen, durch die ich CUxDeamon, RedMatic, XML-API und hm_pdect kennengelernt habe. Danach konnte ich meine umfassende Regeltechnik, nicht zuletzt wegen Deines geeigneten Lehrgangs in Script Programmierung, erstellen. Wahnsinn!!!!

Hallo, das Video passt wie die Faust aufs Auge! Seit zwei Tagen treibt ein HmIP Gerät meinen DC auf 99 %. Vielen Dank für diese Lösungsweg! Es ist unglaublich das es noch kein Programm in der CCU gibt, um ein defektes Gerät mit Bordmitteln zu finden. ELV macht WAS!

Hallo Stefan, habe zu meinen, Dir per eMail mitgeteilten Themen, dieses Video gefunden. Habe den Stick sofort gekauft, auf einem Raspberry Pi die Dockerversion von AskSinAnalyzer XS installiert. Es läuft seit Tagen erfolgreich und erhalte so eine sehr gute Übersicht was alles so bei mir so kommuniziert. Eine wertvolle Ergänzung zur Homematic IP. Wünschte mir, es wäre ein Teil der CCU3 und von Homematic offiziell unterstützt und angeboten. Das Video ist vom Inhalt immer noch sehr aktuell. Danke.

Endlich mal wieder ein Video von dir und endlich wieder ein Infovideo zum Thema Homematic. Das war ein super informatives Video. Danke

@verdrahtet

3 жыл бұрын

Danke für den netten Kommentar :) Ich brauchte ne längere Pause - aber nun geht's wieder los!

868MHz gehört zu den sogenannten ISM Bändern, dazu gehört auch das 433 MHz Band.Als damals, so um 2006 bei ELV bzw. EQ3 nach einem Standard für das FS20 System gesucht wurde, war 433MHz schnell wegen der Überlastung damals aus dem Rennen. 2,4GHz, bzw Zigbee war auch schnell vom Tisch wegen der Lizenzkosten. Ausschlaggebend für 868 war unter anderem der Low Power Mode des CC1100 der damals noch von Chipcon vertrieben/hergestellt wurde. Chipcon wurde später von TI aufgekauft. Ein weiteres Stromspar Feature des CC1100 war Listen before talk. Die Arbeit mit EQ3 damals hat mir sehr viel Spaß bereitet. Sorry für die kleine Story, ist mir gerade alles wieder so eingefallen.

@verdrahtet

3 жыл бұрын

Sehr interessant! Danke für den Einblick

Nice, wusste gar nicht dass es mit Asksin++ so eine Community rund um eigene Homematik-kompatible Hard+Software gibt. Habe in letzter Zeit Sensoren immer mit dem ESP8266 gemacht, aber für batteriebetriebene Geräte ist dieser halt nicht so toll. Nur leider bekommt man zum Preis von einem Arduino + Funkmodul bereits 3 voll bestückte ESP8266 Dev-Boards. Von der Software her schauen die Asksin++ Sketches ganz ok aus, aber wenn man mal von ESPHome verwöhnt ist fragt man sich schon warum man für einen einfachen Aktor/Sensor noch >100 Zeilen Programmcode benötigt statt einer minimalen Konfigurations-Datei. Flashen lässt sich der ESP8266 leichter, bei Dev-Boards gibts direkt MicroUSB oder sonst halt seriellen Adapter, und mit esphome-flasher noch eine nette GUI dazu. Beim Asksin++ braucht man zwingend einen komplizierteren ISP-Programmer um OTA Flash von der CCU verwenden zu können und um den Brown-Out Detector zu deaktivieren da das Ding sonst bei niedrigem Batteriestand zum Dauersender werden kann. Naja ist dann zumindest eine nette Alternative zu Arduino+Zigbee wenn man eine CCU aber kein Zigbee Gateway besitzt. Und btw Homematic könnte ja so eine kleine Anzeige mit den Top3 oder Top10 Modulen, mit denen die CCU kommuniziert, integrieren. Nur halt krass dass die es noch nicht eingebaut haben wenn man bedenkt wie lange es Homematic schon gibt.

Absolut TOP-Video. Regelmässig "verrecken" meine Aktoren nach 2-3 Jahren Betrieb. Meist ist nur ein Elko kaputt, oft ist es auf den ersten Blick "komisch". Aktoren senden auch "Amok", wenn sie defekt sind. nicht nur wenn die Batterie schwächelt. Ich meine Aktoren, die per Ac-Netz betrieben werden. Das Analyse-Tool hab ich mir auf nen RPI0 W installiert und bereits nach kurzer Zeit einen defekten Aktor analysiert. Es wäre schön, wenn ELV das in die CCU integriert, um defekte Aktoren ausfindig zu machen. Das Tool ergänzt diese Info und ist Gold Wert beim Troubleshooting. BTW: Kaputte Aktoren ersetze ich durch "billige Shellys" ...

@verdrahtet

Жыл бұрын

jau - so etwas verstehe ich auch nicht, warum dies nicht implementiert wird. Ebenso - warum muss ich für einen Dimmaktor immer noch eine Einschaltverzögerung kaufen. Warum nicht integrieren?!

Danke, dass du dieses Thema aufgegriffen hast. Echt super. Ich bin mir aber noch nicht sicher, ob ich dein Projekt umsetze, weil es mir zu aufwändig ist. Im Moment ist die "Duty-Cycle-Not" noch nicht groß genug. 😉 Gibt es evtl. noch weitere Tipps, den Duty-Cycle zu reduzieren? Insbesondere in den Einstellungen der Geräte?

@klebepresse

3 жыл бұрын

Mein Tipp wäre: Solange der Duty-Cycle weil unter 50 % ist, noch keine Gedanken machen. Vielleicht wirst du da nie ein Problem mit haben.

@michaeldewitz1940

3 жыл бұрын

Das Intervall der zyklischen Statusmeldungen zu reduzieren ist wohl die einfachste Möglichkeit. Eine weitere Möglichkeit wäre es, alle Aktoren, bzw. alle Geräte, welche man ansteuern kann und bei denen das irgendwie möglich ist, im Netzbetrieb zu betreiben. Dafür gibt es z.B einen Unterputz-Adapter, welcher an 230v angeschlossen wird und aus welchem dann zwei batterieformige Kontakt rausstehen, auf welche man diverse Aktoren dann einfach mit dem Batteriefach aufstecken kann. Der Vorteil für den Duty Cycle besteht darin, daß der Aktor nun nicht mehr in den Schlafmodus wechseln muss, um Strom zu sparen und deswegen auch nicht mit einem Duty Cycle intensiven Burst aus dem Schlafmodus aufgeweckt werden muss. Bei Sensoren, welche eh nie von der Zentrale oder einem anderen Aktor Befehle erhalten, sondern nur selbst Funkkontakt zu anderen Geräten aufnehmen (Öffnungssensoren z.B.) bringt das natürlich nichts, weil diese niemals auf einen Burst warten sondern immer alleine entscheiden, wann Funkkontakt mit einem Partner aufgenommen wird. Für den Batterieverbrauch der übrigbleibenden Geräte, welche noch auf Bursts lauschen, ist das auch positiv, weil jeder Burst alle Geräte die so aufgeweckt werden können, auch alle Geräte kurz aufwachen lässt. Je weniger Geräte also auf Bursts angewiesen sind, umso seltener werden welche verschicken und umso seltener wachen Deine batteriebetriebenen Aktoren auf und verbrauchen kurzzeitig viel Strom.

Danke für die gute Erklärung. Ich habe mir auch, wegen DC Probleme, den Stick gekauft und mit dem Analyzer mitgeschrieben. Wo kann ich nachlesen, wie ich bei einem virtuellen Kanal den hohen DC verbessern kann?

Habe mir den AskSin Analyzer komplett in Hardware aufgebaut (CC1001, ProMini, Lolin ESP32 mit LiPo Akku & TFT) und bin total begeistert. Hut ab an die Entwickler!!! Durch Dein Video ist mir allerdings ein Unterschied im Webinterface aufgefallen: Im (aktuellen) WebUI des ESP (Firmware 3.4) fehlt die recht hilfreiche Spalte DC für den DutyCyle. Ist das ein Design-Unterschied, oder habe ich eine Einstellung übersehen?

@verdrahtet

3 жыл бұрын

Gute Frage - das habe ich bei mir nicht getestet (cooler Aufbau btw.) - In den Einstellungen hat man hier keine Möglichkeit dies ein oder auszublenden.

3:23 Wenn der Sensor die CCU nicht erreicht, es deshalb immer wieder versucht und somit den Duty Cycle voll macht, wie kann die CCU das dann überhaupt mitbekommen und kann es visualisieren bzw. eine Fehlermeldung geben? 🤔

@mrconfidence

3 жыл бұрын

Darüber bin ich auch gestolpert - ich denke, es ist eher umgekehrt. Die CCU versucht ständig einen Sensor zu erreichen, dessen Batterie leer oder schwach ist und der sich deshalb nicht zurückmeldet... Es gibt übrigens für iOS Geräte eine simple App namens "HM Batterie", die die Batteriezustände aller eingebundenen Geräte ausliest und übersichtlich darstellt. So können schwache Batterien schnell entlarvt werden.

3:43 Ich dachte die CCU nutzt eh nur 50% des Duty Cycle um Gerätefirmware zu übertragen. Da jedes einzelne Update deutlich mehr als 50% des Duty Cycle einer einzelnen Stunde für den Transfer zum Gerät verbraucht, wird doch eh immer 50% des Duty Cycle verwendet und das stundenlang auch wenn ich nur ein einzelnes Update übertrage. Das einzelne Update ist dann schneller vollständig am Ziel angekommen, aber für den Duty Cycle habe ich doch so gar nichts erreicht.

Wie finde ich den den Port heraus, den ich auswählen muss?

Funktioniert diese Erfassung auch mit Access Point?

@verdrahtet

3 жыл бұрын

Das klappt leider nicht

Kann man mit dem Stick/Programm auch um Störer zu finden? Duty Cycle ist normal, aber Carrier Sense dauerhaft bei 100%

@verdrahtet

2 жыл бұрын

oh - das weiss ich leider nicht. So einen Fehler hatte ich noch nicht

Welch krankes System!

Wenn ein Meldet mit schwacher Batterie versucht seinen Status zu senden und bei der CCU kommt das nicht an, sollte doch der DutyCicle auch nicht hoch zählen? Oder habe ich das falsch verstanden?

@hundhome

3 жыл бұрын

Jedes Gerät (CCU als auch jeder Aktor/Sensor) hat als Sender seinen eigenen Duty Cycle. Im genannten Beispiel geht zunächst nicht der DC der CCU hoch, sondern der des Geräts. Die CCU geht dann hoch, wenn sie versucht ein Gerät mit schwacher Batterie anzupingen, dass aber aufgrund der schwachen Batterie nicht antworten kann. Dann versucht die CCU es immer wieder und treibt sich selbst hoch. Verstärkt wird der Hochschaukel-Effekt noch, wenn bei HmIP eine Reichweitenverlängerung durch einen Router stattfindet, weil jeder Kommunikationsversuch zur doppelten Menge an Signalen und Retrys führt.

@zlausi1967

3 жыл бұрын

@@hundhome Danke, so versteht es sich.