Homematic und Investitionsschutz

Begonnen von Rampler, 17 Oktober 2017, 08:09:21

Vorheriges Thema - Nächstes Thema

zap

Zitat von: marvin78 am 08 November 2017, 14:20:18
So weit ich weiß, hat Qivicon HM bei eq3 lizensiert. Ggf. kommen hier 2 "peinliche" Protokolle zusammen ;)

Welche beiden Protokolle meinst Du? Qivicon hat kein eigenes Protokoll. Die nutzen Zigbee, BidCos-RF und HM-IP.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

marvin78

Zitat von: zap am 08 November 2017, 16:34:41
Welche beiden Protokolle meinst Du? Qivicon hat kein eigenes Protokoll. Die nutzen Zigbee, BidCos-RF und HM-IP.


::)  Es sollte ein Scherz sein. Mit "Protokoll" (ja, ich hätte es ebenfalls in Anführungszeichen setzen sollen) meine ich das ganze Qivicon-Konstrukt, das nicht gerade auf stabilen Füßen steht.

fiedel

Vielleicht kann man Qivicon das Protokoll abjagen, indem man so ein Teil softwaremäßig seziert?  ;)
Und mal noch hypothetischer: Es gibt doch diese Eigenentwicklung für den Drehgriffkontakt - vielleicht lassen sich damit IP- Komponenten auf Classic umflashen, oder sogar ein verschlüsseltes Open- Source- Funkprotokoll nachrüsten...
Wenn ich was in den vergangenen 6 Jahren mit FHEM gelernt habe, dann dass nichts unmöglich ist. :)
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

zap

Zitat von: fiedel am 08 November 2017, 20:03:52
Vielleicht kann man Qivicon das Protokoll abjagen, indem man so ein Teil softwaremäßig seziert?  ;)

Na dann fang mal an und gib Bescheid wenn du fertig bist und die Sache auch mit den Anwälten von EQ3 klar gemacht hast.   ::)
Aber wieso sollte jemand sich die Mühe machen, das Rad nochmal zu erfinden, wenn doch die Integration von HMIP per CCU (ob Software oder Hardware) in FHEM, OpenHAb und IOBroker jetzt schon möglich ist.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

Pfriemler

Zitat von: fiedel am 08 November 2017, 20:03:52
... vielleicht lassen sich ... IP- Komponenten auf Classic umflashen ...
Boah ... das wäre genial. Nur muss man dann eigentlich ein ganzes Device neu kreieren.

Zitat von: zap am 08 November 2017, 21:03:16
Aber wieso sollte jemand sich die Mühe machen, das Rad nochmal zu erfinden...

denn darauf liefe es ja da auch hinaus.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

CoolTux

Qivicon wird ne fertige Javaclass für Homematic von EQ3e bekommen haben und gut ist. Und da ist nicht Mal alles drin. Register setzen können die schon Mal gar nicht und selbst sowas einfach wie peeren unterstützen die nicht. Da kannste nicht Mal eben einen fremden Tempsensor virtuell an ein HM Device binden. Genau das fällt den Gerade bei deren Kunden auf die Füße. Selbst das Homematic Wandthermostat diehnt nur zum einstellen der Temp über Qivicon und das war es auch schon. Die gemessene Temp wird nur angezeigt aber nicht übertragen. measured-temp kommt ausschließlich von den HT direkt und somit direkt an der Wärmequelle. HomematicIP kennt kein offSet. Tja was soll ich sagen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

fiedel

Zitat von: zap am 08 November 2017, 21:03:16
Na dann fang mal an und gib Bescheid wenn du fertig bist und die Sache auch mit den Anwälten von EQ3 klar gemacht hast.   ::)
Naja, das mit den Anwälten leuchtet mir ja auch ein, aber wie ist es denn mit dem Classic- oder FS20- Protokoll? Das wurde doch auch von irgendjemandem mühevoll reengineert und nun hier quasi offiziell verwendet? Oder ist das Open Source?
Zitat
Aber wieso sollte jemand sich die Mühe machen, das Rad nochmal zu erfinden, wenn doch die Integration von HMIP per CCU (ob Software oder Hardware) in FHEM, OpenHAb und IOBroker jetzt schon möglich ist.
Weil so eine CCU (soft oder hard ) für die Meisten ein umständlicher Umweg ist und (hard) ein unnötiger Stromverbraucher.
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

marvin78

Es gibt noch mehr Nachteile einer CCU und den Umweg darüber (bspw. die Anzahl der IOdevs).


Ich habe ein sehr sehr umfangreiches HM Sortiment in meinem Haus verbaut (mit 8 IODevs), neue Dinge werden aber mit ZWave umgesetzt, wenn es geht. Da habe ich auch keinen Investitionsschutz aber ich hoffe einfach, dass hierauf lange Sicht mehr "möglich" ist, als mit Homematic. Im Detail gehört das aber natürlich hier nicht hin.

zap

Zitat von: fiedel am 09 November 2017, 04:29:46
Naja, das mit den Anwälten leuchtet mir ja auch ein, aber wie ist es denn mit dem Classic- oder FS20- Protokoll? Das wurde doch auch von irgendjemandem mühevoll reengineert und nun hier quasi offiziell verwendet? Oder ist das Open Source?Weil so eine CCU (soft oder hard ) für die Meisten ein umständlicher Umweg ist und (hard) ein unnötiger Stromverbraucher.

Was jetzt daran einfacher sein soll, sich in FHEM mit Peering u d Pairing abzumühen statt in der CDU einfach mit ein paar Mausklicks komplette Räume zu verbinden (Heizungsgruppen) erschliesst sich mit jetzt nicht.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

marvin78

Mit templates ist das in FHEM auch nicht so schwer und es sieht so aus, als wäre eine "Oberfläche" dafür nicht mehr so weit weg. In dem Moment, an dem sowas existiert, hat die CCU für HM Classic keinerlei Vorteile mehr.


Aber das ist eine wenig eine Glaubensfrage und ggf. auch einigermaßen offtopic, wenn auch nicht ganz.

NewMatic

Bin kompletter FHEM, bzw. auch HM Neuling.

Hab mir bis jetzt einen Raspberry Pi3+ HM-MOD-RPI-PCB bestellt.

Würdet ihr in meiner Situation, als Neuling generell zu HM IP raten oder HM?
Mein derzeitiger Fokus liegt auf der Jalousiensteuerung.
Es gibt HM "basic" Aktoren für ca 56euro
die HM IP Jalousienaktoren kosten um ca 10 euro mehr (66euro).

Sind HM IP Geräte für mich als Neuling schwerer zu konfigurieren?

Bin um jegliches Feedback dankbar!

LG Tobi

Pfriemler

Das ist sowohl eine technische als auch eine Glaubensfrage. Für HM-IP brauchst Du in jedem Fall eine weitere Zentrale, entweder eine CCU2 oder die Software YAHM parallel zu FHEM auf dem Raspi, und dazu eine Koppelmöglichkeit zu FHEM, wofür sich aktuell nur zap's HMCCU-Modul anbietet.

Was für Dich optimal ist, richtet sich nach dem Plan bei Dir. Suchst Du nur eine einfache Oberfläche mit klickundfertig für ein paar Konfigs und einfache Programme, reicht Dir evtl. schon die CCU2 bzw. YAHM (beides m.W. gleichwertig bzw. letzteres sogar besser). Planst Du umfängliche unterschiedliche Hardwarefamilien zu vereinen und hast Spaß an der Kommandozeile, ist FHEM ohne HMIP überlegenswert. Den meisten Aufwand, Fehlerquellen, aber auch die meisten Möglichkeiten bietet die o.g. Kombi aus beiden Welten.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

NewMatic

Eine weitere Zentrale brauche ich nur, wenn ich auf der derzeit angedachten (Raspberry+HM Funkmodul) das normale HM laufen lasse?


Cobra

Es gibt nur den Bausatz bei HM Basic, daher findest das auch nicht auf Amazon.

https://www.elv.de/homematic-jalousiesteuerung.html
FHEM in Docker auf Synology, CCU3,
Diverse HM-Komponenten, Netatmo, Hue, Sonos, Nuki