HmIP-BSM Firmware?

HMIP Sender und Empfänger der Serie Homematic IP

Moderator: Co-Administratoren

Daimler
Beiträge: 9115
Registriert: 17.11.2012, 10:47
System: Alternative CCU (auf Basis OCCU)
Wohnort: Köln
Hat sich bedankt: 37 Mal
Danksagung erhalten: 283 Mal

Re: HmIP-BSM Firmware?

Beitrag von Daimler » 06.11.2021, 11:36

crandler hat geschrieben:
06.11.2021, 10:01
eQ-3 juckt das überhaupt nicht
Aber je mehr Freds dort zu dem Thema eröffnet werden, umso peinlicher wird es. :wink:
Hier ist es nur ein rufen in den Wald - das hier ist ein User für User Forum :!:

Tipps, wie man das notfalls anders lösen kann, gibt es hier zur Genüge - einer steht einen Beitag über meinem. :mrgreen:
Nehmt sie an oder ruft ...
Gruß Günter

pivccx mit 3.xx in Produktiv und Testsystem mit HM-, HM-W, HMIP- und HMIP-W Geräten, HPCx Studio 4.1,
L-Gateways, RS-L-Gateways, HAP, Drap, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM / HM-IP: Zur Zeit knapp 300 Komponenten mit ??? Kanälen .

Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!

Xel66
Beiträge: 14165
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 585 Mal
Danksagung erhalten: 1500 Mal

Re: HmIP-BSM Firmware?

Beitrag von Xel66 » 06.11.2021, 11:46

crandler hat geschrieben:
06.11.2021, 10:01
Meiner Meinung nach ist Homematic für "größere" Installationen einfach ungeeignet, wenn man regelmäßig alle Updates einspielen möchte.
Es gibt Anwender, die wohl recht große Installationen betreiben. Von denen liest man hier aber bezüglich dieser Problematik weniger. Aber Homematic trägt ja das Home schon im Namen und ist eben für Installationen bis zur Größe von normalen Einfamilienhäusern gedacht. Und das packt das System im Normalfall auch problemlos. Hier wird der Updateproblematik aber eine Bedeutung zugemessen, die dem Problem nicht ansatzweise gerecht wird. Was stört es, wenn das System mehrere Wochen braucht, um alle gleichartigen Aktoren upzudaten? Im Normalfall läuft das System währenddessen doch problemlos (zwar mit erhöhtem Duty Cycle) weiter. Der Duty Cycle ist aber auch das einzige wirkliche Problem daran. Die einzige Limitierung die besteht, ist nun mal in repeateten Netzen oder welche die den HAP enthalten, weil hier die implementierte Duty Cycle-Begrenzung auf 50% nicht greift und das System sich selbst auf den Bauch legt. Bei den Updates geht es bisher in keinem Fall um sicherheitsrelevante Fehlerbeseitigung, sondern maximal funktionelle Updates oder welche, die die Stabilität verbessern. Der Zwang, diese in kurzer Zeit einzuspielen ist einfach nicht gegeben und das Problem wird hier m.E. nur künstlich aufgebauscht. Noch dazu kommt, das solche Updates nur in vergleichsweise großen Abständen veröffentlicht werden. Es ist ja definitiv nicht so, dass die Aktoren mehrmals im Jahr ein Update benötigen. Im Gegenteil!

Meines Erachtens ist es sogar zielführend, in repeateten Funkstrecken keine Updates zu fahren, da hier die Belegung des Funkbandes schlichtweg verdoppelt wird, weil der Repeater jedes empfangene Funkpaket für den entfernten Empfänger nochmals aussenden muss. Gerade bei den IP-Geräten ist wegen des "listen before talk" ein möglichst wenig dauerhaft belegtes Funkband notwendig. Die Sache mit dem HAP ist wieder ein anderes Ding. Hier handelt es sich um eine nachträglich angeflanschte Krücke für Anwender mit flächenmäßig ausgedehnter Installation, um die Funkabdeckung zu gewährleisten. Vermutlich lassen sich in der gewachsenen Struktur der Firmware solche nachträglichen Zusätze nicht voll funktional implementieren, so dass zwar die Steuerung und Konfiguration gelingt, aber eben keine Updates. Schließlich ist der Unterbau ja auch schon etwa betagt und wird seit der CCU1 mitgeschleppt. Darum halte ich persönlich auch nichts von den Installation der Zentrale im Keller um dann das selbst geschaffene Defizit mit irgendwelchen Repeatern, Gateways und Accesspoints auszugleichen. Die CCU gehört in die Mitte des abzudeckenden Funkbereiches und schon gar nicht in den Keller. So, wie man es bei WLAN auch macht. Das ist nun mal bei Funksystemen so. Und wer es anders betreibt, muss eben mit Einschränkungen leben. Um mal wieder einen Autovergleich zu bemühen: Wer sein Auto unbedingt tieferlegen will, muss bei Schlaglöchern, Bordsteinkanten und schlechter Fahrbahn eben vorsichtig fahren, damit das geliebte Fahrzeug nicht aufsetzt. Das ist dann weder dem Hersteller noch dem Eigner der Straße (wobei Schlaglöcher beseitigt gehören) anzulasten, sondern eine Entscheidung des Besitzers.

Als Lösung des Problems kann man entweder den Propheten (sprich: Aktor) zum Berg (sprich: CCU) schicken oder den Berg zum Propheten bringen. In Systemen mit HAP sollte der Tausch CCU gegen HAP das kleinere Problem sein, wenn man nicht wieder ein Konstrukt gewählt hat welches einen solchen Tausch verhindert (Virtualisierung auf einem anderen Rechner, den man nicht mal so schnell woanders aufbauen kann). In allen anderen Fällen muss man eben den Aktor ausbauen und in die Nähe der CCU bringen (ja, ich weiß, dass das mit gewissem Aufwand verbunden ist) oder eben den Workaround mit einer zweiten CCU (die alte 2er aus dem Reserveregal) benutzen. Einfach Aktor lokal werksresetten --> an der Reserve-CCU anmelden --> updaten --> werksresetten --> und am produktiven System "drüberanlernen" --> fertig. Das sollte in einem Minimum der Zeit abgelaufen sein. Dass man in der Zeit des Updates mit einer Kommunikationsstörung auf dem produktiven System leben muss, versteht sich von selbst, weil der Aktor ja währenddessen wegend es Werksresets nicht mehr auf den ehemaligen Herrn hört. Möglichkeiten gibt es schon. Es ist nur nicht so einfach, wie man es sich wünschen würde und mit etwas "Arbeit" verbunden - aber lösbar. Die Energie, die manche reinstecken, um den Status Quo hier im Forum zu beweinen und bejammern, wäre in einer solchen Lösung des Problems besser angelegt. Ich gehe mit dem Updateproblem noch pragmatischer um. Ich schaue, ob ich vom "Problem" betroffen bin und lasse dann das Update einfach sein, wenn ich es nicht benötige. Im Falle eines FSI16 (und der hatte wirklich ein funktionelles Problem, welches das ganze System in die Knie gezwungen hat) habe ich den Weg mit der Reserve-CCU gewählt. Wobei der Aktor immer noch im Probebetrieb dran hängt, weil ich inzwischen am gepanten Einbauort etwas anderes verbaut habe.

Das Grundproblem ist mehr der dem Anwender durch viele Geräte, die eines Updates aus Sicherheitsgründen bedürfen, antrainierte "Beißreflex" sofort jedes "Update" einspielen zu müssen, weil sonst das eigene Gerät "gefährdet" ist.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

crandler
Beiträge: 10
Registriert: 22.07.2020, 22:42
System: CCU
Hat sich bedankt: 1 Mal
Danksagung erhalten: 1 Mal

Re: HmIP-BSM Firmware?

Beitrag von crandler » 07.11.2021, 11:28

In vielen Punkten gebe ich dir Recht - in einigen aber nicht. :P
Der Vergleich mit dem Auto ist Käse, da hier ja nur originale Homematic-Komponenten verwendet werden. Wenn das Homematic nicht unterstützt, muss es wenigstens eine Warnmeldung ausgeben nach dem Motto "Halt Stopp! Wenn du jetzt auf Update drückst, schießt du dir in 3-4 Wochen dein System komplett ab". Das ist ein reiner Designfehler - sonst nichts.

Das Beispiel mit dem WLAN ist Quatsch. Es spricht nichts dagegen, mehrere Access Points (per Netzwerkkabel angebunden) auf unterschiedlichen Kanälen (z. B. 1, 6, 11) zu betreiben, um eine optimale Verteilung der Funksignale zu bekommen. Die WLAN-Konfiguration kann man sogar so aufbauen, dass man gar keine Funklöcher mehr hat. Ein "WLAN" mitten im Haus ist ungefähr so, wie nur eine Lampe mitten im Haus, die alle Zimmer beleuchten soll. Bei einer komplett offenen Bauweise mag das vielleicht funktionieren ... :-)

Mir geht es überhaupt nicht darum, dass ein Update in Sekunden eingespielt sein muss. Selbstverständlich kann man auch warten, bis man es überhaupt startet oder man wartet auf das nächste oder übernächste Update. Und der Updatevorgang an sich darf auch gerne länger dauern - er muss halt zuverlässig sein. Irgendwann MUSS man aber ein Update installieren - z. B. wenn es aufgrund eines Sicherheitsproblems notwendig wird, weil es einen fiesen Bug gibt oder, weil die Firmware der CCU die Version der angebundenen Komponenten nicht mehr richtig unterstützt. Das funktioniert dann halt entweder nicht oder man betreibt sein System wissentlich mit einem (Sicherheits)-Problem über mehrere Wochen mit wahrscheinlichen Ausfällen und viel Gefrickel. Das ist überhaupt nicht "Endlich. Einfach. Smart Home." Von "Leben Sie leicht, unkompliziert und entspannt: mit den Komfortlösungen von Homematic IP." kann da auch keine Rede sein.

frd030
Beiträge: 3622
Registriert: 14.07.2019, 20:49
System: CCU
Hat sich bedankt: 847 Mal
Danksagung erhalten: 542 Mal

Re: HmIP-BSM Firmware?

Beitrag von frd030 » 07.11.2021, 12:20

crandler hat geschrieben:
07.11.2021, 11:28
Das funktioniert dann halt entweder nicht oder man betreibt sein System wissentlich mit einem (Sicherheits)-Problem über mehrere Wochen mit wahrscheinlichen Ausfällen und viel Gefrickel. Das ist überhaupt nicht "Endlich. Einfach. Smart Home." Von "Leben Sie leicht, unkompliziert und entspannt: mit den Komfortlösungen von Homematic IP." kann da auch keine Rede sein.
Ich liebe überflüssige Grundsatzdiskussionen und bezweifle, dass das aktuelle BSM-Update irgendein Sicherheitsproblem löst (das wäre bei einem Update der Zentrale anders!).

Also zurück zum eigentlichen Thema: ich habe bisher in den letzten Jahren und Monaten schon FW-Updates auf ein gutes Dutzend HmIP-(P/F)S(M) und fast ebensoviele SWDO, dazu noch diverse eTRV, WTH-2, etc. durchgeführt. Nach zwei Tagen waren alle durch, immer! Der DC war immer im Rahmen und ich nutze dazu auch das Produktivsystem.

Also Du hast ein Problem, das haben wir verstanden! Bisher hast Du uns allerdings wenig zu Deinem System verraten (HAP oder ein anderes Gerät als Repeater im Spiel? Haben die Geräte generell eine gute / schlechte Funkverbindung? Wie sind sie verbaut? etc.?)!

Beschwerden bitte an den Hersteller, hier führen sie zu nichts, ausser zu häufig überflüssigen Grundsatzdiskussionen.
Wenn Du Hilfe erwartest -> Informationen bitte!

Xel66
Beiträge: 14165
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 585 Mal
Danksagung erhalten: 1500 Mal

Re: HmIP-BSM Firmware?

Beitrag von Xel66 » 07.11.2021, 12:33

crandler hat geschrieben:
07.11.2021, 11:28
Das ist ein reiner Designfehler - sonst nichts.
Nein, ist er eben nicht. Das würde nämlich voraussetzen, dass das System so wie es jetzt ist, von Anfang an so geplant (designt) wurde. Wurde es aber definitiv nicht. Als die Grundlagen gelegt wurden, war an IP noch nicht mal zu denken und erst recht nicht an einen abgesetzten umfunktionierten Accesspoint (der per Design eigentlich eine grundverschiedene Funktion - aka Cloudanbindung - hat) in Verbindung mit einer CCU. Wie oben bereits geschrieben wurde diese Möglichkeit nachträglich und leider nicht voll funktional hinzugefügt. Er soll zur Funkabedeckung im Betrieb dienen. Und das tut er.
crandler hat geschrieben:
07.11.2021, 11:28
Das Beispiel mit dem WLAN ist Quatsch.
Nein ist es nicht - nur Dein Verständnis von Funkausbreitung weicht etwas von etablierten Meinungen und den physikalischen Gesetzmäßigkeiten ab. Es ist immer noch Stand der Technik, ein funkendes Zentralgerät möglichst in der Mitte des zu versorgenden Funkbereiches aufzustellen. So werden auch Funkzellen für Mobilkommunikation geplant. Ihnen wird eine Bereich zugewiesen, den sie zu versorgen haben und die Antennen entsprechend ausgerichtet. Der Multistationsbetrieb solcher Zellen aber auch eine WLAN-Versorgung ist grundsätzlich anders aufgebaut und eben nicht mit einer CCU vergleichbar. Hier regelt jedes Gerät den Transport der Nutzdaten selbst. Bei einer CCU ist das Design so, dass es nur einen einzigen Master gibt, der die Kommunikation und Verbindung regelt. Der ganze Kram mit Gateway und HAP ist nur nachträglich drangebastelt und im Falle von IP nur für die Konfiguration und Betrieb aber eben nicht voll funktionsfähig (Updates). Dass dieser Zustand unbefriedigend ist und nach Möglichkeit geändert gehört, steht auf einem ganz anderen Blatt.
crandler hat geschrieben:
07.11.2021, 11:28
Ein "WLAN" mitten im Haus ist ungefähr so, wie nur eine Lampe mitten im Haus, die alle Zimmer beleuchten soll. Bei einer komplett offenen Bauweise mag das vielleicht funktionieren ... :-)
Sorry, dieser Vergleich ist noch quätscher. Im Gegensatz zu Funkwellen kann Licht feste Materie nicht passieren. Ich hatte früher ein zweieinhalbgeschossiges Altbaureihenhaus (BJ: 1904 Massivbau mit Holzzwischendecken) mit genau einer FritzBox im OG. Diese hat das ganze Haus mit WLAN abgedeckt. Eine Lampe im gleichen Raum hätte prinzipbedingt das Haus nicht ausleuchten können. Dein Vergleich hinkt mehr als der von Äpfeln und Birnen.
crandler hat geschrieben:
07.11.2021, 11:28
Irgendwann MUSS man aber ein Update installieren - z. B. wenn es aufgrund eines Sicherheitsproblems notwendig wird, weil es einen fiesen Bug gibt oder, weil die Firmware der CCU die Version der angebundenen Komponenten nicht mehr richtig unterstützt.
MUSS nicht unbedingt, denn wegen Sicherheitproblemen auf der Funkschnittstelle wurde bisher noch kein Update gelauncht, soweit ich mich erinnern kann. Es ging meist um funktionale Sachen oder eben eine Fehlerbereinigung. Ganz abgesehen davon, dass die ersten klassischen Geräteserien nicht mal für den Nutzer über die Funkschnittstelle updatebar waren. Und noch mal: betreibt man eine CCU mit einem HAP zur Funkabdeckungserweiterung, betreibt man ein System, wie es ursprünglich per Design nicht so ausgelegt war. Es ist wie immer. Der Hersteller hat eine Funktion für einen speziellen Anwendungsfall nachgereicht (kleiner Finger) und der Anwender will gleich die volle Funktionalität (ganze Hand). Das heißt nicht, dass das vielleicht noch kommen könnte und die Nichtfunktionalität derzeit ein Bug ist (wovon ich ausgehe). Die Auskunft kann Dir aber nur der Hersteller geben. Das hier zu diskutieren ist müßig, denn hier ist ein Anwenderforum. Wer von dem Problem betroffen ist und den Hersteller zum Handeln veranlassen will, muss diesem eben auf den Sack gehen. Und das möglichst zahlreich.
crandler hat geschrieben:
07.11.2021, 11:28
Das ist überhaupt nicht "Endlich. Einfach. Smart Home." Von "Leben Sie leicht, unkompliziert und entspannt: mit den Komfortlösungen von Homematic IP." kann da auch keine Rede sein.
Hier kann ich Dir dann nur raten, das System, zu dem dieser Werbespruch gehört einzusetzen - undzwar so, wie es der Hersteller vorsieht. Dann funktioniert es auch. Wenn Du es unbedingt anders willst (auch ich würde keine Cloudlösung einsetzen wollen), dann musst Du mit funktionellen Einschränkungen in bestimmten Bereichen leben oder einen anderen Hersteller einsetzen. Ich bin lange genug dabei und könnte mir aus der Erfahrung vorstellen, wie der Hersteller das Problem vermutlich "löst". Er schreibt einen Satz dazu, dass für Updates das upzudatende Gerät sich im Funkbereich des Zentralenfukmoduls befinden muss. So ähnlich wurde es ja auch mit dem eher nicht vorhandenen Zugriffschutz auf das Webinterface (Stichwort: Portweiterleitung) gemacht.

Und Möglichkeit das upzudatende Gerät in den Funkbereich der Zentrale zu verbringen hat jeder Anwender selbst, denn er hat das System (welches ja als DIY-System vertrieben wird) ja mit relativ hoher Wahrscheinlichkeit selbst aufgebaut. Die Systeme, die durch einen Systemintegrator aufgebaut wurden, werden zahlenmäßig wahrscheinlich im Promille-Bereich liegen und haben mit relativ hoher Sicherheit keine solche Frickellösung implementiert. Deren Anwender werden auch wiederum mit hoher Wahscheinlichkeit kein Update einspielen. Es mag aber Ausnahmen geben. Wenn man also unterstellt, dass der Anwender über die notwendige Sachkenntnis zur Installation verfügt, weil er es ja selbst gemacht hat, kann er auch das Gerät für das Update in den Funkbereich bringen. Er muss also keineswegs mit dem Status Quo leben. Dass das natürlich ein erhöhter Aufwand ist, der bei einer updatefähigen Verbindung nicht notwendig wäre, steht auch wieder auf einem anderen Blatt. Es ist wie es ist. Man kann den Zustand beklagen (eine ziemlich deutsche Eigenschaft), aussitzen oder ganz pragmatisch handeln. Ich habe mich in meinem Falle für das Zweite entschieden, da ich keine dringende Notwendigkeit sehe.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

MichaelN
Beiträge: 9679
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 700 Mal
Danksagung erhalten: 1626 Mal

Re: HmIP-BSM Firmware?

Beitrag von MichaelN » 07.11.2021, 13:11

Da kann man noch so lange Romane schreiben, Fakt ist, das EQ3 die Updatefunktion verbockt hat. QED.
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

frd030
Beiträge: 3622
Registriert: 14.07.2019, 20:49
System: CCU
Hat sich bedankt: 847 Mal
Danksagung erhalten: 542 Mal

Re: HmIP-BSM Firmware?

Beitrag von frd030 » 07.11.2021, 13:25

Und was machen wir jetzt konkret mit dieser gewaltigen Erkenntnis? Hilft sie in irgendeiner Weise beim konkreten Problem? Kann irgendjemand hier das Updateverfahren ändern oder verbessern? Nein? Dachte ich mir…. :mrgreen:

Xel66
Beiträge: 14165
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 585 Mal
Danksagung erhalten: 1500 Mal

Re: HmIP-BSM Firmware?

Beitrag von Xel66 » 07.11.2021, 14:17

frd030 hat geschrieben:
07.11.2021, 13:25
Kann irgendjemand hier das Updateverfahren ändern oder verbessern?
Nö, denke ich auch nicht, darum ist ja das Auskotzen über die fehlerhafte Arbeitsweise hier im Forum auch der falsche Weg. Zumal es absolut keine neue Erkenntnis und schon vielfach hier im Forum dokumentiert ist. Ich habe es nur versucht, etwas etwas nachvollziehbarer auszuführen, Alternativen aufzuzeigen und diplomatischer auszudrücken. Wer damit ein Problem hat, soll sich an den Support des Händlers/(Herstellers) wenden und dort seinen Unmut ablassen.

Ich kann auch nicht nachvollziehen, warum viele Anwender mit Gewalt andere Installationen als eine möglichst nahe am Original durchführen müssen, wenn sie dann doch mit den sich daraus ergebenden Konsequenzen überfordert sind. Sicher kann man das als Lernobjekt benuztzen. Aber wenn ich sehe, dass manche unbedingt ohne ein Mindestmaß an Netzwerk-KowHow und technischem Verständnis (z.B. Funkausbreitung) eine virtualisierte Installation aufsetzen müssen und das auf Funkkommunikation angewiesene Zentralgerät mit Antenne unterhalb des Geländeniveaus (Keller) installieren, dann ist ein solches Projekt schlichtweg als Einstieg in die Materie ungeeignet. Dann wird wieder versucht, diese Defizit mit noch mehr Hardware auszugleichen (was in diesem Falle nun leider mal nicht funktioniert). Zumal die meisten Anwender dabei (außer Erkenntnissen) im täglichen Betrieb eines Smarthomes nicht mal was gewinnen.

Selbst unter ökologischen Gesichtspunkten (und da geht es nach meiner Beobachtung häufig nach dem Motto "koste es was es wolle) ist eine solche Entscheidung nicht nachvollziehbar. In vermutlich dem überwiegenden Anteil der Installationen wäre eine am Original orientierte Zentrale (Pi3 und Charly) die zielführende und vor allem funktionierende Alternative gewesen. Aber soll jeder machen wie er will. Man kann sich bei wirklichen Problemen auch helfen lassen, aber das Gejammere nervt irgendwie (leider kann ich manchmal dem Schutzreflex "Tab wegklicken" widerstehen und muss mich dann doch äußern). Sicherhlich ist diese Implementation des HAPs verbockt, aber der Ansprechpartner und der Einzige, der das ändern kann, ist nun mal der Hersteller. Und leider reicht es nicht, einfach zu schreiben "wende Dich an den Support".

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

frd030
Beiträge: 3622
Registriert: 14.07.2019, 20:49
System: CCU
Hat sich bedankt: 847 Mal
Danksagung erhalten: 542 Mal

Re: HmIP-BSM Firmware?

Beitrag von frd030 » 07.11.2021, 15:08

Xel66 hat geschrieben:
07.11.2021, 14:17
Nö, denke ich auch nicht, darum ist ja das Auskotzen über die fehlerhafte Arbeitsweise hier im Forum auch der falsche Weg.
:!: q.e.d.

UweRLP
Beiträge: 311
Registriert: 22.07.2013, 08:44
System: CCU
Hat sich bedankt: 13 Mal
Danksagung erhalten: 8 Mal

OF:

Beitrag von UweRLP » 09.11.2021, 08:24

Steigerung von Quatsch :lol:
noch quätscher
Uwe
--------------------------------------------
CCU3, ioBroker unter Windows 10 auf einem HP EliteDesk 800 G1 mit Intel(R) Core(TM) i5-4570S
Abgesichert mit einer APC Back-UPS Pro 1500 mit externem Batterie Pack BR24BPG
--------------------------------------------

Antworten

Zurück zu „HomeMatic IP Aktoren und Sensoren“