NEWS
Störungen bei HmIP-BSM
-
@Homoran said in Störungen bei HmIP-BSM:
@legro sagte in Störungen bei HmIP-BSM:
doppelte Nutzung der Aktoren (short und long press)
mit long press habe ich allerdings auch bei HmIP Sendern meine Probleme (gehabt???)
Ich hatte vor paar Tagen einiges umkonfiguriert und seitdem noch nicht (aufHolzKlopf) wieder Probleme gehabt
Da ich überhaupt keine Idee habe, was hier bei mir los ist, habe ich mich dazu entschlossen, ein altes SD-Karten-Image wiederherzustellen, das aus Zeiten stammt, in denen die HmIP-BSM noch nicht den Aufstand probten und diese bloß einfach in Schaltungen mit Wechsel- und Kreuzschalter eingebunden waren.
Dank deiner Antworten weiß ich wenigstens, dass ich wohl doch nicht alleine bin, wenn‘s um Probleme mit Homematic geht.
Könnte deiner Einschätzung nach auch die Verwendung von piVCCU3 eine Rolle spielen? Immer, wenn ich eingefleischte Homematic Nutzer frage, will keiner meine Sorgen ernst nehmen - man hat noch nie solche Probleme gehabt.
Unter MSH/Qivicon gab‘s kaum ein Tag, an dem nicht irgendein Homematic Gerät Fehler meldete. Also dachte ich, dass die Entwicklungsabteilung einfach bloß unfähig ist. Hier muss ich wohl Abbitte leisten.:grimacing:
@legro sagte in Störungen bei HmIP-BSM:
wohl doch nicht alleine bin, wenn‘s um Probleme mit Homematic geht.
"Probleme" liegen meist in falschen Konfigurationen. So hatte ich z.B. Routing aktiv aktivieret, obwohl ich gar kein Routig-fähiges Gerät in meinem System habe.
Seit ich den Haken wieder rausgenommen habe ist (bis jetzt!) Ruhe@legro sagte in Störungen bei HmIP-BSM:
man hat noch nie solche Probleme gehabt.
Habe ich ja auch nicht.
@legro sagte in Störungen bei HmIP-BSM:
Könnte deiner Einschätzung nach auch die Verwendung von piVCCU3 eine Rolle spielen?
aus zwei Gründen nicht ;-)
- ich nutze piVCCU, nicht piVCCU3! ;-)
- die Firmware ist identisch mit der entsprechenden CCU-Version
@legro sagte in Störungen bei HmIP-BSM:
kaum ein Tag, an dem nicht irgendein Homematic Gerät Fehler meldete
ich habe bereits seit Jahren eine sehr umfangreiche HM-Installation und noch nie solche Fehler gehabt, außer ich habe sie selbst verbockt:
- mehr als x Firmwareupdates gefahren -> DC am Anschlag
- Gerät außer Betrieb genommen ohne es abzumelden -> DC am Anschlag beim nächsten Neustart
- leere Batterien in einem Gerät (muss nicht HM sein, andere 868MHz Geräte mit leeren Batterien gelten auch!) -> Gerät versucht immer wieder sich zu melden, beim Senden bricht die Spannung zusammen -> Reboot und der Zyklus beginnt von Vorne. Auch hier die Folge: Äther zugemüllt oder auch der DC am Anschlag.
Alles das führt zu Komm-Störungen.
Aber auch wenn die Ursachen der Probleme gar nicht bei dir liegen.
Es gab mal einen Fall, da hatte ein Bauträger eine ganze Siedlung dichtstehender Häuser mit HomeMatic Finkkomponenten ausgestattet. Diese haben sich teilweise gegenseitig lahmgelegt.Natürlich können es auch bauliche Probleme sein, wenn das Funkpaket auf direktem Weg durch dickes (oder langes) Mauerwerk soll.
Ein flacher Winkel ist ein vielfaches schlimmer als eine dicke Wand -
@legro sagte in Störungen bei HmIP-BSM:
wohl doch nicht alleine bin, wenn‘s um Probleme mit Homematic geht.
"Probleme" liegen meist in falschen Konfigurationen. So hatte ich z.B. Routing aktiv aktivieret, obwohl ich gar kein Routig-fähiges Gerät in meinem System habe.
Seit ich den Haken wieder rausgenommen habe ist (bis jetzt!) Ruhe@legro sagte in Störungen bei HmIP-BSM:
man hat noch nie solche Probleme gehabt.
Habe ich ja auch nicht.
@legro sagte in Störungen bei HmIP-BSM:
Könnte deiner Einschätzung nach auch die Verwendung von piVCCU3 eine Rolle spielen?
aus zwei Gründen nicht ;-)
- ich nutze piVCCU, nicht piVCCU3! ;-)
- die Firmware ist identisch mit der entsprechenden CCU-Version
@legro sagte in Störungen bei HmIP-BSM:
kaum ein Tag, an dem nicht irgendein Homematic Gerät Fehler meldete
ich habe bereits seit Jahren eine sehr umfangreiche HM-Installation und noch nie solche Fehler gehabt, außer ich habe sie selbst verbockt:
- mehr als x Firmwareupdates gefahren -> DC am Anschlag
- Gerät außer Betrieb genommen ohne es abzumelden -> DC am Anschlag beim nächsten Neustart
- leere Batterien in einem Gerät (muss nicht HM sein, andere 868MHz Geräte mit leeren Batterien gelten auch!) -> Gerät versucht immer wieder sich zu melden, beim Senden bricht die Spannung zusammen -> Reboot und der Zyklus beginnt von Vorne. Auch hier die Folge: Äther zugemüllt oder auch der DC am Anschlag.
Alles das führt zu Komm-Störungen.
Aber auch wenn die Ursachen der Probleme gar nicht bei dir liegen.
Es gab mal einen Fall, da hatte ein Bauträger eine ganze Siedlung dichtstehender Häuser mit HomeMatic Finkkomponenten ausgestattet. Diese haben sich teilweise gegenseitig lahmgelegt.Natürlich können es auch bauliche Probleme sein, wenn das Funkpaket auf direktem Weg durch dickes (oder langes) Mauerwerk soll.
Ein flacher Winkel ist ein vielfaches schlimmer als eine dicke WandVielen Dank für deinen ausführlichen und ermutigenden Beitrag.
Bei mir - so hat‘s den Anschein - verbockt jedoch nicht bloß unsereiner etwas, da finde ich offenbar kräftig Unterstützung bei Homematic.:grimacing:
Nachdem tagelang die HmIP-BSM Geräte nahezu mein gesamtes System lahmlegten und ich kein Land mehr sah, hätte ich am liebsten den ganzen Homematic-Kram in die Tonne geklopft.
Meine Erfahrungen mit dem Rückzug auf eine (ur)alte Implementierung (SD-Karten-Image) ließ mich wieder Hoffnung schöpfen. Die Anlage lief - bis auf die wohl bei Homematic üblichen „Servicemeldungen“ mehr als 24h zufriedenstellend. Akribisch verglich ich die beiden Konfigurationen miteinander, bevor ich wieder die aktuelle Version in Betrieb nahm, um direkt nach dem Start die vermutlich zu diesen Fehler führenden Konfigurationen zurückzubauen. Jetzt melden die sieben HmIP-BSM nur noch vereinzelte Kommunikationsstörungen. Das System ist mithin in einem leidlich stabilen Zustand.
Die Schilderung deiner Erfahrungen bestärken mich zweifach: Zum Einen hinsichtlich meiner Einschätzung über die Qualität und Zuverlässigkeit:thinking_face: des Homematic-Systems, zum Anderen darin, nicht gleich aufzugeben.:relaxed: Insbesondere deine Ausführungen zur piVCCU3 beruhigen mich.:+1:
Apropos Funk ..
Hier verdienen sich die Homematic-Entwickler gewiss keine Lorbeeren. Da hätte man die Geräte gewiss besser ausstatten können.
So hat insbesondere einer der HmIP-BSM ganz entscheidenden Anteil an dem Störungsszenario. Er meldete seit Wochen(!) in Verbindung mit Kommunikationsstörungen immer hin und wieder, dass er (fälschlicherweise) ein Update auf 2.12.18 haben möchte oder dass Konfigurationsdaten vorlägen oder .. oder .. Heute habe ich ihn zurückgesetzt, seither scheint er sich beruhigt zu haben.
Jetzt hoffe ich, dass ich endlich wieder Zeit finde, unser Alarmsystem aufzubauen. Hierzu verwende ich BITRON Rauchmelder 902010/24 und Außensirene 902010/29. Dank @Asgothian, der mir mein System gepatcht hat, kann ich diese Geräte universell als Alarmgeber verwenden.
Zu Zeiten von MSH/Qivicon konnte ich die BITRON Geräte nur mittels des ZigBee Meshs der OSRAM lightify Lampen leidlich mit Funk versorgen. Nun setze ich den Coordinator CC26X2R1 von Texas Instruments ein, der direkt alle Geräte so stabil anbindet, wie ich‘s mir von Homematic auch wünschen würde.
Nach über vier Jahren Leidenszeit unter Qivicon/MSH vor den Telekomikern zu ioBroker geflüchtet.
Raspberry Pi 4 mit 8GB + ArgonOneM.2 + 120GB SSD + Coordinator CC26X2R1 + ioBroker + piVCCU3 -
Vielen Dank für deinen ausführlichen und ermutigenden Beitrag.
Bei mir - so hat‘s den Anschein - verbockt jedoch nicht bloß unsereiner etwas, da finde ich offenbar kräftig Unterstützung bei Homematic.:grimacing:
Nachdem tagelang die HmIP-BSM Geräte nahezu mein gesamtes System lahmlegten und ich kein Land mehr sah, hätte ich am liebsten den ganzen Homematic-Kram in die Tonne geklopft.
Meine Erfahrungen mit dem Rückzug auf eine (ur)alte Implementierung (SD-Karten-Image) ließ mich wieder Hoffnung schöpfen. Die Anlage lief - bis auf die wohl bei Homematic üblichen „Servicemeldungen“ mehr als 24h zufriedenstellend. Akribisch verglich ich die beiden Konfigurationen miteinander, bevor ich wieder die aktuelle Version in Betrieb nahm, um direkt nach dem Start die vermutlich zu diesen Fehler führenden Konfigurationen zurückzubauen. Jetzt melden die sieben HmIP-BSM nur noch vereinzelte Kommunikationsstörungen. Das System ist mithin in einem leidlich stabilen Zustand.
Die Schilderung deiner Erfahrungen bestärken mich zweifach: Zum Einen hinsichtlich meiner Einschätzung über die Qualität und Zuverlässigkeit:thinking_face: des Homematic-Systems, zum Anderen darin, nicht gleich aufzugeben.:relaxed: Insbesondere deine Ausführungen zur piVCCU3 beruhigen mich.:+1:
Apropos Funk ..
Hier verdienen sich die Homematic-Entwickler gewiss keine Lorbeeren. Da hätte man die Geräte gewiss besser ausstatten können.
So hat insbesondere einer der HmIP-BSM ganz entscheidenden Anteil an dem Störungsszenario. Er meldete seit Wochen(!) in Verbindung mit Kommunikationsstörungen immer hin und wieder, dass er (fälschlicherweise) ein Update auf 2.12.18 haben möchte oder dass Konfigurationsdaten vorlägen oder .. oder .. Heute habe ich ihn zurückgesetzt, seither scheint er sich beruhigt zu haben.
Jetzt hoffe ich, dass ich endlich wieder Zeit finde, unser Alarmsystem aufzubauen. Hierzu verwende ich BITRON Rauchmelder 902010/24 und Außensirene 902010/29. Dank @Asgothian, der mir mein System gepatcht hat, kann ich diese Geräte universell als Alarmgeber verwenden.
Zu Zeiten von MSH/Qivicon konnte ich die BITRON Geräte nur mittels des ZigBee Meshs der OSRAM lightify Lampen leidlich mit Funk versorgen. Nun setze ich den Coordinator CC26X2R1 von Texas Instruments ein, der direkt alle Geräte so stabil anbindet, wie ich‘s mir von Homematic auch wünschen würde.
@legro sagte in Störungen bei HmIP-BSM:
Er meldete seit Wochen(!) in Verbindung mit Kommunikationsstörungen immer hin und wieder, dass er (fälschlicherweise) ein Update auf 2.12.18 haben möchte oder dass Konfigurationsdaten vorlägen oder .. oder ..
Die Updates von HmIP laufen etwas anders als von HomeMatic.
Es kann tatsächlich so gewesen sein, wie du meinst, dass es nicht ist ;-)HmIP Updates werden scheibchenweise -teilweise über mehrere Tage- von der CCU auf die Aktoren verteilt um den DutyCycle nicht unnötig in die Höhe zu treiben.
Dazu gehen sie nur bis der DC einen bestimmten Wert erreicht hat (z.B. 60/80%) stoppen dann, warten eine Zeit bis der DC wieder unter einen Schwellwert fällt und machen dann weiter.
In der Zeit steht halt das Update noch an.Hat deine Installation jedoch sowieso ein Problem und zeitweise einen hohen DC, kann es passieren, dass nach dem Erreichen des oberen Schwellwertes die Restmenge an freiem DC nicht mehr ausreicht und anschließend der DC überschritten ist, was zu der Kommunikationsstörung führt.
Ein Reset setzt diesen DC (des Aktors!!!!) wieder auf 0 -
@legro sagte in Störungen bei HmIP-BSM:
Er meldete seit Wochen(!) in Verbindung mit Kommunikationsstörungen immer hin und wieder, dass er (fälschlicherweise) ein Update auf 2.12.18 haben möchte oder dass Konfigurationsdaten vorlägen oder .. oder ..
Die Updates von HmIP laufen etwas anders als von HomeMatic.
Es kann tatsächlich so gewesen sein, wie du meinst, dass es nicht ist ;-)HmIP Updates werden scheibchenweise -teilweise über mehrere Tage- von der CCU auf die Aktoren verteilt um den DutyCycle nicht unnötig in die Höhe zu treiben.
Dazu gehen sie nur bis der DC einen bestimmten Wert erreicht hat (z.B. 60/80%) stoppen dann, warten eine Zeit bis der DC wieder unter einen Schwellwert fällt und machen dann weiter.
In der Zeit steht halt das Update noch an.Hat deine Installation jedoch sowieso ein Problem und zeitweise einen hohen DC, kann es passieren, dass nach dem Erreichen des oberen Schwellwertes die Restmenge an freiem DC nicht mehr ausreicht und anschließend der DC überschritten ist, was zu der Kommunikationsstörung führt.
Ein Reset setzt diesen DC (des Aktors!!!!) wieder auf 0Definitiv gab‘s bei uns keine Probleme mit dem duty cycle. Auch waren alle Updates bereits vor Wochen abgeschlossen. Jedem HomematicIP-Aktor ließ ich genügend Zeit, sich in aller Ruhe sein Update zu ziehen. Hierzu überwachte ich den duty cycle, der - wie du bestätigst - nie die Grenze von ca. 70% überschritt.
Warum urplötzlich einer der HmIP-BSM-Aktoren meinte, das bereits installierte Update erneut anfordern zu müssen, bleibt wohl nun für immer sein Geheimnis.
Was mich jedoch überrascht, ist die Qualität meines ZigBee-Netzes. Im Gegensatz zu BidCos - mit seinen 868MHz - traten bisher keinerlei Störungen auf, obwohl in den für die Ausbreitung in Gebäuden ungünstigen 2,4GHz Bändern gesendet wird.
Sei‘s d‘rum. Ich habe nunmal die vielen Homematic Geräte und muss wohl oder übel mit ihnen auskommen. Das hat schließlich wochenlang ja auch zufriedenstellend funktioniert.
Nochmals vielen Dank für deine Unterstützung.
-
@legro sagte in Störungen bei HmIP-BSM:
Er meldete seit Wochen(!) in Verbindung mit Kommunikationsstörungen immer hin und wieder, dass er (fälschlicherweise) ein Update auf 2.12.18 haben möchte oder dass Konfigurationsdaten vorlägen oder .. oder ..
Die Updates von HmIP laufen etwas anders als von HomeMatic.
Es kann tatsächlich so gewesen sein, wie du meinst, dass es nicht ist ;-)HmIP Updates werden scheibchenweise -teilweise über mehrere Tage- von der CCU auf die Aktoren verteilt um den DutyCycle nicht unnötig in die Höhe zu treiben.
Dazu gehen sie nur bis der DC einen bestimmten Wert erreicht hat (z.B. 60/80%) stoppen dann, warten eine Zeit bis der DC wieder unter einen Schwellwert fällt und machen dann weiter.
In der Zeit steht halt das Update noch an.Hat deine Installation jedoch sowieso ein Problem und zeitweise einen hohen DC, kann es passieren, dass nach dem Erreichen des oberen Schwellwertes die Restmenge an freiem DC nicht mehr ausreicht und anschließend der DC überschritten ist, was zu der Kommunikationsstörung führt.
Ein Reset setzt diesen DC (des Aktors!!!!) wieder auf 0@Homoran said in Störungen bei HmIP-BSM:
Ein Reset setzt diesen DC (des Aktors!!!!) wieder auf 0
Hiermit bringst du mich auf eine Idee.
Bisher habe ich immer nur den duty cycle der piVCCU3 mir angeschaut. Nach dem, was du schreibst, könnte ggf. der duty cycle des HmIP-BSM überschritten sein.
Kann man das irgendwo sehen?
Nach über vier Jahren Leidenszeit unter Qivicon/MSH vor den Telekomikern zu ioBroker geflüchtet.
Raspberry Pi 4 mit 8GB + ArgonOneM.2 + 120GB SSD + Coordinator CC26X2R1 + ioBroker + piVCCU3 -
@Homoran said in Störungen bei HmIP-BSM:
Ein Reset setzt diesen DC (des Aktors!!!!) wieder auf 0
Hiermit bringst du mich auf eine Idee.
Bisher habe ich immer nur den duty cycle der piVCCU3 mir angeschaut. Nach dem, was du schreibst, könnte ggf. der duty cycle des HmIP-BSM überschritten sein.
Kann man das irgendwo sehen?
@legro sagte in Störungen bei HmIP-BSM:
Kann man das irgendwo sehen?
Jein!
es gibt in Kanal einen State für den Duty Cycle.
der ist aber nur Bool, also ja/nein. ich weiß nicht wann der auf true gehtschlimmstenfalls erst bei 100%, wobei bei 99% auch nicht wirklich ein ganzes Paket durch kommt.
Aber eine Störung des Funkverkehrs ist immer noch eine Möglichkeit, insbesondere wenn der Aktor ständig dagegen anfunkt und dadurch zusätzlich in das Limit des DC kommt
-
Vorab: Hier findet ihr die Zusammenfassung und Lösung der in diesem Thread diskutierten Fehler.
Vorgeschichte ..
Ende Sommer wechselte ich von MagentaSmartHome (MSH alias Qivicon) - um dem dort herrschenden Chaos zu entfliehen - und flüchtete mich zu ioBroker. Den Schritt habe ich nicht nur nicht bereut, sondern es war eine meiner besten Entscheidungen.
In einem Punkt muss ich wohl im Nachhinein die Leute in der Entwicklungsabteilung von MSH fast schon in Schutz nehmen. Die vielen Störungen gingen größtenteils auf Homematic Geräte zurück. Und genau diese Störungen beobachte ich nun auch unter ioBroker.
Konfigurationen ..
Ich betreibe ioBroker und piVCCU3 (in einem LXC) auf einem RaspberryPi 4 mit 8GB RAM. Als Funkmodul wählte ich das leistungsstärkere Bauteil RPI-RF-MOD. Darüber hinaus verwende ich für ZigBee (3.0) den Coordinator CC26X2R1 von Texas Instruments. Als weitere über (W)LAN angeschlossene Gerätschaften betreibe ich HUE, Shelly, ..
Jeden HmIP-BSM nutze ich i.d.R. zweifach. Kurzer Tastendruck: Gerät ein/aus; langer Tastendruck: weitere Aktionen.
HmIP-RF/BidCos-Probleme ohne Ende ..
Gelang es mir bei vielen Aktoren (Rollläden, Funktaster, Funkschalter, ..) unter Verwendung der Datenpunkte in ioBroker viele Störungen zu erkennen und durch Nachsteuern leidlich im Zaum zu halten, so bin ich beim HmIP-BSM mittlerweile ratlos. Mit wachsendem Ausbau unseres Systems nahmen die Störungen (allerdings nur im Homematic Bereich) beständig zu.
Schlimmer noch: Diese Teile proben derzeit regelrecht den Aufstand, wie man an nachfolgender Abbildung erkennen kann. Kaum ein Aktor, der sich daran nicht beteiligt.
Störungsmeldungen von meinen HmIP-BSMs
Hilferuf ..
Hat jemand hier Erfahrung mit Homematic(IP) Geräten und insbesondere dem HmIP-BSM und kann mir ggf. raten?
@legro said in Störungen bei HmIP-BSM:
Ich betreibe ioBroker und piVCCU3 (in einem LXC) auf einem RaspberryPi 4 mit 8GB RAM. Als Funkmodul wählte ich das leistungsstärke Bauteil RPI-RF-MOD.
Das große Funkmodul passt nicht ohne weiteres auf einen Pi4.
Hast du einen Stacking Header benutzt oder eine der USB- oder Ethernet-Lösungen von Alex Reinert (HB-RF-USB* oder HB-RF-ETH)?Der Pi4 ist für starke Störstrahlung bekannt und deswegen ist es schwierig, ein HM-Funkmodul direkt daran zu betreiben.
Mit HB-RF-USB* oder HB-RF-ETH geht es gut. -
Definitiv gab‘s bei uns keine Probleme mit dem duty cycle. Auch waren alle Updates bereits vor Wochen abgeschlossen. Jedem HomematicIP-Aktor ließ ich genügend Zeit, sich in aller Ruhe sein Update zu ziehen. Hierzu überwachte ich den duty cycle, der - wie du bestätigst - nie die Grenze von ca. 70% überschritt.
Warum urplötzlich einer der HmIP-BSM-Aktoren meinte, das bereits installierte Update erneut anfordern zu müssen, bleibt wohl nun für immer sein Geheimnis.
Was mich jedoch überrascht, ist die Qualität meines ZigBee-Netzes. Im Gegensatz zu BidCos - mit seinen 868MHz - traten bisher keinerlei Störungen auf, obwohl in den für die Ausbreitung in Gebäuden ungünstigen 2,4GHz Bändern gesendet wird.
Sei‘s d‘rum. Ich habe nunmal die vielen Homematic Geräte und muss wohl oder übel mit ihnen auskommen. Das hat schließlich wochenlang ja auch zufriedenstellend funktioniert.
Nochmals vielen Dank für deine Unterstützung.
-
@legro sagte in Störungen bei HmIP-BSM:
Kann man das irgendwo sehen?
Jein!
es gibt in Kanal einen State für den Duty Cycle.
der ist aber nur Bool, also ja/nein. ich weiß nicht wann der auf true gehtschlimmstenfalls erst bei 100%, wobei bei 99% auch nicht wirklich ein ganzes Paket durch kommt.
Aber eine Störung des Funkverkehrs ist immer noch eine Möglichkeit, insbesondere wenn der Aktor ständig dagegen anfunkt und dadurch zusätzlich in das Limit des DC kommt
Die boolsche Variable hatte ich bereits überprüft. Meine Hoffnung war, dass es auch bei Geräten ggf. eine Prozentangabe geben mag.
Zu keiner Zeit war die boolsche Variable auf true.
-
@legro said in Störungen bei HmIP-BSM:
Ich betreibe ioBroker und piVCCU3 (in einem LXC) auf einem RaspberryPi 4 mit 8GB RAM. Als Funkmodul wählte ich das leistungsstärke Bauteil RPI-RF-MOD.
Das große Funkmodul passt nicht ohne weiteres auf einen Pi4.
Hast du einen Stacking Header benutzt oder eine der USB- oder Ethernet-Lösungen von Alex Reinert (HB-RF-USB* oder HB-RF-ETH)?Der Pi4 ist für starke Störstrahlung bekannt und deswegen ist es schwierig, ein HM-Funkmodul direkt daran zu betreiben.
Mit HB-RF-USB* oder HB-RF-ETH geht es gut.Schon klar, ohne Stack Header kann man das Funkmodul natürlich nicht betreiben.
Ich habe bewusst mich für das große BidCos-Modul entschieden, weil ich es außerhalb des Gehäuses anbringen möchte. Ein kleines Funkmodul im Inneren eines Aluminiumgehäuses wäre wohl auch nicht sinnvoll.:confused:
Alle Geräte liefen seit Mitte August zunächst wochenlang zufriedenstellend. Erst in den letzten Tagen gibt's Störungen, von denen ich einfach nicht die Ursachen erkennen kann.
Nach tagelangem Rumbasteln verbleiben vorwiegend nur die Störungen an den HmIP-BSM. Eine beliebte Fehlermeldung ist hier zu sehen ..
Die HmIP-BSM werden u.a. über Bewegungsmelder eingeschaltet. Die Störungen äußern sich darin, dass die Lampen oft nicht eingeschaltet werden. Allein Abwarten kann dazu führen, dass es wieder die nächsten Male funktioniert.
Ich bin ratlos.
Nach über vier Jahren Leidenszeit unter Qivicon/MSH vor den Telekomikern zu ioBroker geflüchtet.
Raspberry Pi 4 mit 8GB + ArgonOneM.2 + 120GB SSD + Coordinator CC26X2R1 + ioBroker + piVCCU3 -
Schon klar, ohne Stack Header kann man das Funkmodul natürlich nicht betreiben.
Ich habe bewusst mich für das große BidCos-Modul entschieden, weil ich es außerhalb des Gehäuses anbringen möchte. Ein kleines Funkmodul im Inneren eines Aluminiumgehäuses wäre wohl auch nicht sinnvoll.:confused:
Alle Geräte liefen seit Mitte August zunächst wochenlang zufriedenstellend. Erst in den letzten Tagen gibt's Störungen, von denen ich einfach nicht die Ursachen erkennen kann.
Nach tagelangem Rumbasteln verbleiben vorwiegend nur die Störungen an den HmIP-BSM. Eine beliebte Fehlermeldung ist hier zu sehen ..
Die HmIP-BSM werden u.a. über Bewegungsmelder eingeschaltet. Die Störungen äußern sich darin, dass die Lampen oft nicht eingeschaltet werden. Allein Abwarten kann dazu führen, dass es wieder die nächsten Male funktioniert.
Ich bin ratlos.
@legro said in Störungen bei HmIP-BSM:
BidCoS ist der Name für den klassischen HomeMatic-Funk ;)Ein Funkmodul im Inneren eines metallischen Gehäuses ohne externe Antenne ist tatsächlich nicht sinnvoll.
Ob diese Zwischenplatine des Argon One sich allerdings neutral gegenüber der Einkopplung von Störungen verhält ist fraglich. Außerdem hat eQ-3 extra die Spannungsversorgung am RPI-RF-MOD vorgesehen und nicht über den Pi.
Wahrscheinlich spielt das alles zusammen und führt zu den Kommunikationsstörungen der HmIP-BSMs.
Was sagen denn die Servicemeldungen in der CCU-Oberfläche?
Kommt da eine Kommunikationsstörung bei dem XML-RPC Error? Geht die wieder weg?
Auf deinem ersten Screenshot sind da ja permanente Störungen und nicht nur ein verlorenes Telegramm. -
Schon klar, ohne Stack Header kann man das Funkmodul natürlich nicht betreiben.
Ich habe bewusst mich für das große BidCos-Modul entschieden, weil ich es außerhalb des Gehäuses anbringen möchte. Ein kleines Funkmodul im Inneren eines Aluminiumgehäuses wäre wohl auch nicht sinnvoll.:confused:
Alle Geräte liefen seit Mitte August zunächst wochenlang zufriedenstellend. Erst in den letzten Tagen gibt's Störungen, von denen ich einfach nicht die Ursachen erkennen kann.
Nach tagelangem Rumbasteln verbleiben vorwiegend nur die Störungen an den HmIP-BSM. Eine beliebte Fehlermeldung ist hier zu sehen ..
Die HmIP-BSM werden u.a. über Bewegungsmelder eingeschaltet. Die Störungen äußern sich darin, dass die Lampen oft nicht eingeschaltet werden. Allein Abwarten kann dazu führen, dass es wieder die nächsten Male funktioniert.
Ich bin ratlos.
@legro sagte in Störungen bei HmIP-BSM:
Erst in den letzten Tagen gibt's Störungen, von denen ich einfach nicht die Ursachen erkennen kann.
es gibt die Möglichkeit mit einem DVB-T Receiver (oder einem teuren Spezialgerät) den Funkverkehr im 868 MHz Bereich zu überprüfen, ob es da Störungen gibt.
@legro sagte in Störungen bei HmIP-BSM:
Eine beliebte Fehlermeldung ist hier zu sehen .
Das sieht aber aus, als ob der Adapter keine Verbindung zur CCU hätte
-
Schon klar, ohne Stack Header kann man das Funkmodul natürlich nicht betreiben.
Ich habe bewusst mich für das große BidCos-Modul entschieden, weil ich es außerhalb des Gehäuses anbringen möchte. Ein kleines Funkmodul im Inneren eines Aluminiumgehäuses wäre wohl auch nicht sinnvoll.:confused:
Alle Geräte liefen seit Mitte August zunächst wochenlang zufriedenstellend. Erst in den letzten Tagen gibt's Störungen, von denen ich einfach nicht die Ursachen erkennen kann.
Nach tagelangem Rumbasteln verbleiben vorwiegend nur die Störungen an den HmIP-BSM. Eine beliebte Fehlermeldung ist hier zu sehen ..
Die HmIP-BSM werden u.a. über Bewegungsmelder eingeschaltet. Die Störungen äußern sich darin, dass die Lampen oft nicht eingeschaltet werden. Allein Abwarten kann dazu führen, dass es wieder die nächsten Male funktioniert.
Ich bin ratlos.
@legro Hast du schon mal versucht die Befehle leicht zeitversetzt zu senden? Ich hatte ein ähnliches Problem mit einer Sirene. Nachdem ich eine kleine Verzögerung eingebaut hatte, gibt es keine derartigen Meldungen mehr.
-
@legro Hast du schon mal versucht die Befehle leicht zeitversetzt zu senden? Ich hatte ein ähnliches Problem mit einer Sirene. Nachdem ich eine kleine Verzögerung eingebaut hatte, gibt es keine derartigen Meldungen mehr.
@Dr-Bakterius said in Störungen bei HmIP-BSM:
@legro Hast du schon mal versucht die Befehle leicht zeitversetzt zu senden? ..
Die Ansteuerungen der HmIP-BSM erfolgen über Bewegungsmelder (BWM), wobei ein BWM immer nur einen Aktor einschaltet. Mithin kann ich hier nichts optimieren.
Zur Steuerung unserer insgesamt 17 Rollläden setze ich natürlich das Ganze so um, wie du‘s hier vorschlägst. Ohne dieses Vorgehen könnte ich auch gleich selbst durch‘s Haus laufen, um sie zu schließen bzw. öffnen.:confused:
Das System kommt mir ziemlich unausgereift vor. Dank ioBroker habe ich ja nun mittlerweile Geräte von vielen Hersteller in Betrieb. Solche Störungen treten bei uns nur bei Homematic Geräten auf.
Seltsam ist dabei, dass es zuweilen lange Zeit gut geht, um dann mal wieder so auszusehen, als würden die Geräte einen regelrechten Aufstand proben.:cry:
Nach über vier Jahren Leidenszeit unter Qivicon/MSH vor den Telekomikern zu ioBroker geflüchtet.
Raspberry Pi 4 mit 8GB + ArgonOneM.2 + 120GB SSD + Coordinator CC26X2R1 + ioBroker + piVCCU3 -
@Dr-Bakterius said in Störungen bei HmIP-BSM:
@legro Hast du schon mal versucht die Befehle leicht zeitversetzt zu senden? ..
Die Ansteuerungen der HmIP-BSM erfolgen über Bewegungsmelder (BWM), wobei ein BWM immer nur einen Aktor einschaltet. Mithin kann ich hier nichts optimieren.
Zur Steuerung unserer insgesamt 17 Rollläden setze ich natürlich das Ganze so um, wie du‘s hier vorschlägst. Ohne dieses Vorgehen könnte ich auch gleich selbst durch‘s Haus laufen, um sie zu schließen bzw. öffnen.:confused:
Das System kommt mir ziemlich unausgereift vor. Dank ioBroker habe ich ja nun mittlerweile Geräte von vielen Hersteller in Betrieb. Solche Störungen treten bei uns nur bei Homematic Geräten auf.
Seltsam ist dabei, dass es zuweilen lange Zeit gut geht, um dann mal wieder so auszusehen, als würden die Geräte einen regelrechten Aufstand proben.:cry:
@legro sagte in Störungen bei HmIP-BSM:
Seltsam ist dabei, dass es zuweilen lange Zeit gut geht, um dann mal wieder so auszusehen, als würden die Geräte einen regelrechten Aufstand proben.
das sieht definitv nach einer (externen) Störung des Funkverkehrs aus
-
@Dr-Bakterius said in Störungen bei HmIP-BSM:
@legro Hast du schon mal versucht die Befehle leicht zeitversetzt zu senden? ..
Die Ansteuerungen der HmIP-BSM erfolgen über Bewegungsmelder (BWM), wobei ein BWM immer nur einen Aktor einschaltet. Mithin kann ich hier nichts optimieren.
Zur Steuerung unserer insgesamt 17 Rollläden setze ich natürlich das Ganze so um, wie du‘s hier vorschlägst. Ohne dieses Vorgehen könnte ich auch gleich selbst durch‘s Haus laufen, um sie zu schließen bzw. öffnen.:confused:
Das System kommt mir ziemlich unausgereift vor. Dank ioBroker habe ich ja nun mittlerweile Geräte von vielen Hersteller in Betrieb. Solche Störungen treten bei uns nur bei Homematic Geräten auf.
Seltsam ist dabei, dass es zuweilen lange Zeit gut geht, um dann mal wieder so auszusehen, als würden die Geräte einen regelrechten Aufstand proben.:cry:
-
@Dr-Bakterius said in Störungen bei HmIP-BSM:
@legro Hast du schon mal versucht die Befehle leicht zeitversetzt zu senden? ..
Die Ansteuerungen der HmIP-BSM erfolgen über Bewegungsmelder (BWM), wobei ein BWM immer nur einen Aktor einschaltet. Mithin kann ich hier nichts optimieren.
Zur Steuerung unserer insgesamt 17 Rollläden setze ich natürlich das Ganze so um, wie du‘s hier vorschlägst. Ohne dieses Vorgehen könnte ich auch gleich selbst durch‘s Haus laufen, um sie zu schließen bzw. öffnen.:confused:
Das System kommt mir ziemlich unausgereift vor. Dank ioBroker habe ich ja nun mittlerweile Geräte von vielen Hersteller in Betrieb. Solche Störungen treten bei uns nur bei Homematic Geräten auf.
Seltsam ist dabei, dass es zuweilen lange Zeit gut geht, um dann mal wieder so auszusehen, als würden die Geräte einen regelrechten Aufstand proben.:cry:
@legro sagte in Störungen bei HmIP-BSM:
Die Ansteuerungen der HmIP-BSM erfolgen über Bewegungsmelder (BWM), wobei ein BWM immer nur einen Aktor einschaltet.
Direkt auf der CCU oder mit ioBroker? Wenn mit ioBroker, dann versuche mal eine kleine Verzögerung einzubauen. Also BWM geht auf true und erst eine Sekunde später den Befehl für den BSM senden.
-
@legro sagte in Störungen bei HmIP-BSM:
Die Ansteuerungen der HmIP-BSM erfolgen über Bewegungsmelder (BWM), wobei ein BWM immer nur einen Aktor einschaltet.
Direkt auf der CCU oder mit ioBroker? Wenn mit ioBroker, dann versuche mal eine kleine Verzögerung einzubauen. Also BWM geht auf true und erst eine Sekunde später den Befehl für den BSM senden.
@Dr-Bakterius sagte in Störungen bei HmIP-BSM:
Wenn mit ioBroker,
und wenn eine DV in der CCU läuft das Ganze ja nicht über die CCU, sondern das handeln die Geräte direkt miteinander aus.
In solchen Fällen kommt es oft vor, dass der Aktor in der Wand sitzt (jaja, das ist immer der Fall) und der BWN an der gleichen Wand 2m höher und 3m weg.
Damit muss dann das Funkpaket fast 4m durch eine Wand.
Eine 30cm Kalksandsteinmauer ist zwar wahnsinnig dick, wenn man ein Loch dadurch stemmen will, aber mit so einer Strecke nicht zu vergleichen.Jetzt reicht noch die allerkleinste Störung und Schluss ist!
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@Dr-Bakterius sagte in Störungen bei HmIP-BSM:
Wenn mit ioBroker,
und wenn eine DV in der CCU läuft das Ganze ja nicht über die CCU, sondern das handeln die Geräte direkt miteinander aus.
In solchen Fällen kommt es oft vor, dass der Aktor in der Wand sitzt (jaja, das ist immer der Fall) und der BWN an der gleichen Wand 2m höher und 3m weg.
Damit muss dann das Funkpaket fast 4m durch eine Wand.
Eine 30cm Kalksandsteinmauer ist zwar wahnsinnig dick, wenn man ein Loch dadurch stemmen will, aber mit so einer Strecke nicht zu vergleichen.Jetzt reicht noch die allerkleinste Störung und Schluss ist!
@Homoran sagte in Störungen bei HmIP-BSM:
wenn eine DV in der CCU läuft das Ganze ja nicht über die CCU, sondern das handeln die Geräte direkt miteinander aus.
Dann würde im ioBroker aber kein Error im Log erscheinen, oder?
-
@Homoran sagte in Störungen bei HmIP-BSM:
wenn eine DV in der CCU läuft das Ganze ja nicht über die CCU, sondern das handeln die Geräte direkt miteinander aus.
Dann würde im ioBroker aber kein Error im Log erscheinen, oder?
@Dr-Bakterius sagte in Störungen bei HmIP-BSM:
@Homoran sagte in Störungen bei HmIP-BSM:
wenn eine DV in der CCU läuft das Ganze ja nicht über die CCU, sondern das handeln die Geräte direkt miteinander aus.
Dann würde im ioBroker aber kein Error im Log erscheinen, oder?
richtig!
Hier werden zwei Themen gemischt.
Thema 1 isind Kommunikationsstörungen der CCU
Thema 2 ist dass ioBroker die CCU nicht erreicht.Im Prinzip ist der BWM sogar nur ein weiterer Nebenkriegsschauplatz
Das Ganze riecht mir immer mehr nach externen Störeinflüssen
Support us
741
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge