Visualisierungen iOBrooker Homee und mehr

[tomi_cc16]

aber frag mal jemand in der USA oder England, Polen usw. ob der jemals was von Homematic gehört hat.

Da geb ich dir Recht s. auch meine Frage zu Homematic im Ausland:
viewtopic.php?f=19&t=41102

Die Homematic Linie ist doch so oder so schon "abgehängt", d.h. nicht das es nicht genauso wie FS20 weiter verkauft wird, aber wer denkt das es neuere Geräte für Homematic geben wird der wird sehr schnell feststellen das nur noch für Homematic IP neue Geräte herauskommen werden.

Hi, es gehört nur bedingt hier hin, aber warum soll EQ3 großartige Neuerungen im klassichem HM bringen?...
Es wird sicherlich noch mal den ein oder anderen Bausatz im ELV-Journal geben, glaube aber leider, das es max. eine handvoll Bausätze sein werden, die in den nächsten Jahren erscheinen. Der Familienvater

Leider habt ihr beiden Fonzo und Familienvater Recht - HM und HM-IP ist bereits abgehängt und das auf mehreren Ebenen (Design, Anbindung mit Drittherstellern (z.B. HUE), WebUI Design und Bedienbarkeit, Englische Community). Auch erwarte ich das falls es "neue" Geräte geben wird dann nur als HM-IP. Das Problem der Direktverknüpfung zwischen HM und HM-IP werden wir damit wohl nie los.
Aber ich glaube die Basis wird noch ein paar Jahre erhalten bleiben, was danach kommt - wir werden sehen. Vielleicht erleben wir noch mit das es einmal einen "Smart Home" Standard geben wird und Geräte unterschiedlicher Hersteller problemlos miteinander kommunizieren können.

Hier ist eQ3 mit HM-IP vielleicht etwas kurz gesprungen. Finde ich persönlich schade, denn man hätte in die IP Geräte noch das alte Bidcos implementieren können. Bei der zentralengeführten Konfiguration von Direktverknüpfungen könnte die Zentrale den HM-IP-Geräten ja mitteilen, daß der Verknüpfungspartner eine ältere Sprache spricht. Ob das so viel teurer geworden wäre?

Das habe ich mich an einer anderen Stelle im Forum auch gefragt und es bis heute nicht verstanden, gerade das Thema Direktverknüpfungen leidet wie gesagt stark darunter.

[tomi_cc16]

[Z-Wave]
Bin über homee auf fibaro, über aliexpress auf Neo Coolman, über ebay auf Busch-Jäger und über amazon auf Danfoss gestossen.
Die Funkfrequenz läßt ähnliches Potential wie HM erwarten und wenn das Protokoll was taugt und die Geräte ähnlich stromsparend wie HM (Batterie-) Geräte sind, könnte das interessant werden, falls eQ3 die HM-klasschische Line mal "abhängt". Besonders auch wenn sich auch die großen Player wie Busch-Jäger anschliessen und dann wirklich kompatibel und interoperabel bleiben. Besonders Direktverknüpfungen zwischen Produkten verschiedener Firmen fände ich super.

Die Funkreichweite von Z-Wave beträgt im freien Gelände bis zu 200 Meter und im Gebäude, abhängig von den verwendeten Baumaterialien, ca. 30 Meter. Verwendet wird das ISM-Band: in den USA 908,42 MHz, in Europa 868,42 MHz und inzwischen zusätzlich auch das 2.400-MHz-Band. Z-Wave nutzt als Netzwerk-Topologie wie ZigBee ein vermaschtes Netz. Jeder Netzwerkknoten (Sensor oder Aktor) ist mit einem oder mehreren anderen Netzwerkknoten verbunden.

Vielleicht wird es ja irgendwann mal etwas in CuxD oder geben.

Für ioBroker und Z-Wave s.hier
https://youtu.be/c7JmFaKFLP0

https://www.amazon.de/Aeotec-AEOEZW090- ... stick+gen5

Oder *Träum* die neue Produktlinie Homematic Z(-Wave) inkl der neuen CCU3 (die kann dann auch gleich HM, HM-IP und HM-Z)

[klassisch]

Danke @alchy fürs Abtrennen und sorry nochmals @mactools fürs kapern des gekaperten Threads.

Oder *Träum* die neue Produktlinie Homematic Z(-Wave) inkl der neuen CCU3 (die kann dann auch gleich HM, HM-IP und HM-Z)

Mit einer CCU3 bzw. Portierung der SW auf eine gängige Rechnerplatform rechne ich schon. Aber ob dann gleich z-Wave mit integriert wird? Das wäre ja dann das dritte Protokoll im Bereich der HM. Da müßte sich Z-Wave schon als disruptiv erweisen.
Aber vielleicht gibt es mal ein FW-Update für die (oder zumindest neuere, notfalls auch künftige) HM-IP Sensoren, damit sich auch mit HM klassisch-Geräten eine Direktverknüpfung eingehen können?

[Roland M.]

Hallo!

Bei den letzten beiden Usertreffen hat Herr Grohmann zugesichert, daß auch HM klassisch weiterentwickelt wird.

Na ja, meine Interpretation war etwas anders: "Wenn Sie eine CCU haben, wird es dafür auch in Zukunft neue Geräte geben!" Was auch für HmIP-Geräte auf der CCU gegeben ist...


Roland

[Homoran]

Jetzt ja!
Da ist das Zitat wieder dass ich gesucht hatte.
@klassisch:
ich habe das auch so verstanden wie Roland.
Bernd Grohmann meinte meiner Meinung nach, dass HM-klassisch noch lange existieren werde. Aber IMHO nicht, dass dafür noch etwas neues entwickelt werde.


Gruß
Rainer

[Roland M.]

Hallo!

Verwendet wird das ISM-Band: in den USA 908,42 MHz, in Europa 868,42 MHz und inzwischen zusätzlich auch das 2.400-MHz-Band.

Ich fürchte, genau solche gesetzlichen Bestimmungen machen es nicht leicht, Geräte auf anderen Märkten zu positionieren!

Selbst wenn diese unterschiedlichen Frequenzen trotzdem so knapp beieinander liegen, dass keine Hardwareänderung vorgenommen werden muss (was ich als Amateurfunker aber schon ziemlich bezweifle!), so muss zumindest eine eigene Firmware mit der anderen Frequenz bereitgestellt werden. Doppelte Lagerhaltung - doppelte Kosten... Und doppelte Prüfkosten, weil vielleicht auf diesem Markt das CE-Zeichen nicht akzeptiert wird.
Ganz abgesehen von den amerikanischen 110 V vs. "unseren" 230 V.


Roland

[Familienvater]

Hi,

selbst wenn man klassisches HM im HmIP-Aktor selbst und mit 3 Nachfragen aktivieren müsste, kann ich mir nicht vorstellen, das EQ-3 dieses "Funksicherheitsloch" implementieren würde. Stell Dir die Entrüstung vor, das ein TÜV-Sicherheitsgutachten von einem absichtlich "falsch" Konfigurierten HmIP-Aktor durch ein gefaktes, unsigniertes HM-Paket kompromitiert wurde. EQ-3 hat ja "angeblich" nur aus Sicherheitsgründen die dezentralen Wired-Aktoren für UP-Dosen abgekündigt, weil damit der Bus außerhalb des Schaltschranks kompromitierbar gewesen wäre.
Und die Größe der Firmware würde wachsen, weil eben auch der HM-Protokoll-Stack eingebaut werden müsste, mit jeder Zeile Code steigt die Wahrscheinlichkeit, das Fehler im Code sind, die Ressourcen im Aktor sind aber "kostbar und begrenzt", der Mehrwert in wenigen Jahren ggf. hinüber. Eine parallele Entwicklung zu führen, mit HM-Stack, dafür ohne Wochenprogramm etc., oder mit Wochenprogramm, dafür ohne HM-Stack ist doppelter Aufwand (mit geringem Mehrwert).
Wie "entsetzt" sind die Anwender, wenn die nach dem intensiven Lesen der BA rausfinden, das die Routerfunktion in manchen Aktoren nur für HmIP-Pakete zur Verfügung steht, und nicht für HM? Warum würde das so gemacht worden sein?

Andersherum gefragt:
Die Produkentwicklung könnte sich vielleicht in die Richtung bewegen, wenn hier "unendlich" viele Leute Ihr glaubhaftes interesse an bilingualen HmIP-Aktoren bekunden würden.
Bedenke: die Entwicklung der Zusatzfunktion "Jalousiekippwinkel-Verstellung" läßt sich EQ-3 mit 10€ pro Aktor vergüten, wie viel Mehrwert müsste dann die Bilingualität kosten? Sowohl auf Geräte-Firmware-Seite, als auch auf Zentralenseite? Welche Schnittstellenschicht auf der Zentrale wäre für bilinguale Geräte zuständig? Würde der HM-Teil im HmIP-Server mitgemacht? Müsste das Gerät sowohl im rfd für HM und im HmIP-Server für HmIP gehandelt werden? Dann bräuchte das HmIP-Gerät auch eine 24-Bit Funkadresse, und vor allem müsste im HmIP-Gerät auch eine Protokoll-Weiche wie der MultiMac laufen. Es gibt unendlich viele Gründe, warum das nicht machbar ist...

Der Familienvater

[tomi_cc16]

Familienvater ich verstehe deine Bedenken daher hätte ich HM-IP so gelassen wie es ist.

Man könnte aber das ganze Thema Direktverknüpfung auch von Hinten aufziehen.

Alternative1: Nimm die klassischen HM Produkte die mit Direktverknüpfung überhaupt genutzt werden wie z.B. Heizkörperthermostat, Fensterkontakt etc. und bau den HM-Protokoll-Stack per Firmware Update hier ein - damit eine Direkverknüpfung mit HM-IP möglich wird. So schenkst du den Geräten ein zweites Leben. HM-IP bleibt unangetastet und nur wer die Firmware der Altgeräte updatet erhält die Funktion.

Alternative2: Ein "Verknüpfungs-Emulator" im CCU2/Raspi - d.h. die Geräte (HM und HM-IP) sind nur über die Zentrale verknüpft aber nicht direkt. Die Zentrale wäre damit der Übersetzer. Per Einschränkung könnte man nur sinnvolle Szenarien/Verknüpfungen ermöglichen.

Alternative 3: HM Geräte verkaufen und duch HM-IP zu ersetzen ist mir zu teuer.

An anderer Stelle im Forum steht:

Es wird wahrscheinlich darauf hinauslaufen. Das HMIP System wird erweitert und spätestens, wenn dort alle Geräte der klassischen Serie verfügbar sind, wird Homematic das neue FS20.

Und so ist und man kann wahrscheinlich nix mehr dagegen tun

[Familienvater]

Hi,

die HM-Geräte können mangels intergrierter CPU-Power/Speicherplatz auf dem Aktor niemals HmIP.

Soweit ich das aus dem syslog des multimac/rfd rauslese, funkt normales HM mit ~10kBaud Datenübertragungsgeschwindigkeit, HmIP nutzt aber ~100kBaud, deswegen die notwendige "Protokollweiche" multimac, die im Gerät erstmal einige "Takte" mithören müsste, und dann zu entscheiden, das ist langsam, dann muss das bisher Gehörte plus dem kommenden Rest in den HM-Empfangsprotokollteil, oder das ist schnell, das muss in den HmIP-Empfängerteil.

Eine wirklich nicht uninteressante Alternative wäre ggf. wirklich der "Softbabelfish" auf der Zentrale, der den Funkverkehr ganzer Geräte simulieren können müsste. Grundsätzlich ist das wohl möglich, weil AFAIK FHEM z.B. ein Thermostat durch ein "gefaktes" TFK-Funkpaket in den Fenster-Auf-Modus bringen kann. Aber auch das wäre nicht unerheblicher Programmieraufwand auf EQ-3 Seite, die Zentrale die Funkpakete von Sendern "faken" zu lassen. Und auch da wäre wieder das Problem, das dann eigentlich ein Schnittstellenprozess mit einem anderen Schnittstellenprozess sprechen müsste, weil der rfd die 10k-Kommunikation steuert/beherrscht, und der HM-Server die 100k-HmIP-Kommunikation. Und wenn es die Rega machen würde, die eh mit beiden Prozessen spricht, dann.... (und es würde auch erstmal zu weniger Wechsel-Verkäufen führen, weil die Leute zur Zeit die nur die Wahl haben, entweder der ganze "Funktions-/Raum" aus einer Protokollwelt oder nicht verknüpfbar, was gerade bei Heizungsanwendungen ärgerlich ist), wäre ein sanftere Migration möglich, werden Investitionen verschoben, um vielleicht dann in 5 Jahren gleich komplett alles auf HmNG umzustellen. Und die "Penislänge" der Wettbewerber untereinander wird wohl eher in verkauften Stückzahlen untereinander ausgemacht, und nicht in "wir sind die kompatibelsten im Markt", und verkaufen deswegen am wenigsten.

Der Familienvater

[robsdobs]

Alternative 3: HM Geräte verkaufen und duch HM-IP zu ersetzen ist mir zu teuer.

Darauf spekuliert EQ3 sicherlich. Auch wenn es den meisten zu teuer ist, werden genügend Leute ihre Komponenten neu kaufen. Es wird von EQ3 keine Kompatibilität zwischen HM und HMIP geben.

Vom Smartphone gesendet.