FHEM Forum

Hallo!

Hat jemand von euch schon das hier mitbekommen:

http://www.eq-3.de/hausautomation-homematic-ip.html

So wie es aussieht gibt es ab Sommer diesen Jahres eine neue Serie Homematic Komponenten unter dem Namen "Homematic IP".
Folgendes Zitat finde ich dabei am Wichtigsten:

Zitat"Homematic IP Geräte können zusammen mit allen Homematic Geräten mit der CCU2 Smart Home Zentrale betrieben werden. Die Kompatibilität der Lösungen und eine besonders einfache Integration sind sichergestellt."

Was sagt ihr dazu? Wird fhem zu den neuen Devices kompatibel sein?

Gruß,
Mathea

Sorry, leider wurde dieser Beitrag doppelt gepostet. Kann eines der beiden Themen bitte entfernt werden?

interessant finde ich, dass es scheinbar Schalt und Messsteckdosen geben wird, die in einen normalen Rahmen passen, ohne hierfür einen UP Aktor nutzen zu müssen...

Greetz
Eldrik

Liest sich sehr interessant, Danke für den Link.

Jepp.
Die Steckdose klingt spannend :)

Ich finde die Optik auch zeitgemäßer als die aktuellen Homematik Komponenten. Ich frage mich, ob es auch Änderungen im Funkprotokoll geben wird. Zigbee und Z-Wave ist zum Beispiel auch routingfähig, was die Homematic nicht kann. Vielleicht zieht eQ-3 ja nach.

Was ist daran eigentlich IP?

Doch nur der Access Point?! Oder?

Zitat von: CQuadrat am 10 März 2015, 13:57:09
Was ist daran eigentlich IP?

Doch nur der Access Point?! Oder?

dann bräuchte man doch keine neuen devices. ich denke die können dann alle wlan.

WLAN mit Batterien -> was ein Spaß

... und auf die Preisgestaltung bin ich auch sehr gespannt.
VG
Claus

Optik der Steckdosen ist ja mal greisslich bis dorthinaus  :(

Zitat von: frank am 10 März 2015, 13:59:57
dann bräuchte man doch keine neuen devices.

Für's Marketing.

Nix Wlan in allen devices. IPV6 over Bidcos.... entwickeln die schon seit 2010
http://homematic-forum.de/forum/viewtopic.php?f=19&t=5777

Zitat von: CQuadrat am 10 März 2015, 14:03:01
WLAN mit Batterien -> was ein Spaß

nachdem was ich hier http://forum.fhem.de/index.php/topic,28905.0.html (http://forum.fhem.de/index.php/topic,28905.0.html) so gelesen habe, könnte das schon gehen. deep sleep 10uA, glaub ich mich zu erinnern.

Zitat von: HolyMoly am 10 März 2015, 14:10:01
Nix Wlan in allen devices. IPV6 over Bidcos.... entwickeln die schon seit 2010
http://homematic-forum.de/forum/viewtopic.php?f=19&t=5777

möglich ist vieles. wie es aussieht fallen fast alle taster an den thermostaten weg. also nur über handy? mit der 1%-regel wird es dann eventuell eng.

ZitatZuverlässigkeit
Genau wie Homematic setzt Homematic IP auf das 868-MHz-Funkband und kommuniziert durchgehend bidirektional, also mit Rückbestätigung aller Funkbefehle. Störungen durch WLAN-Netze oder Audio- und Video-Streaming sind damit ausgeschlossen. Homematic IP nutzt zudem mehrere Frequenzen und punktet damit insbesondere in größeren Installationen. Seine große Reichweite und die Anwendung des bewährten Homematic-Applikations-protokolls machen das System besonders zuverlässig.

Höchste Sicherheit
Bereits während der Installation des Systems läuft die Kommunikation von Homematic IP gesichert ab und kann nicht manipuliert werden. Im Betrieb sind alle Funkpakete stets verschlüsselt und authentisiert. Ein Mitlesen, Erfinden, Verändern oder Wiederholen von Daten ist ausgeschlossen. Ähnlich wie beim Online Banking werden die universell anerkannten Verfahren AES-128 und CCM eingesetzt.

Einfache Bedienung und Konfiguration
Die Homematic IP-Geräte sind besonders einfach zu installieren und zu konfigurieren. Komplizierte Tastenkombinationen, Bedienermodi oder gar Controller-Arten gehören endgültig der Vergangenheit an. Die intelligente Nutzerführung macht es dem Anwender leicht, das Homematic IP-System Schritt für Schritt zu konfigurieren. Alle notwendigen Verknüpfungen zwischen den einzelnen Komponenten werden automatisch erstellt. Der Anwender kann die Raumklimalösung intuitiv über eine kostenlose Smartphone-App einrichten, die für iOS- (iPhones) und Android-Smartphones zur Verfügung steht. Ein PC ist nicht länger notwendig und die Bedienung des Systems wird für den Benutzer denkbar einfach.

http://www.presseanzeiger.de/pa/Homematic-IP-Das-Smart-Home-spricht-jetzt-IPv6-775192 (http://www.presseanzeiger.de/pa/Homematic-IP-Das-Smart-Home-spricht-jetzt-IPv6-775192)

leider kein wlan.

ZitatHöchste Sicherheit
Bereits während der Installation des Systems läuft die Kommunikation von Homematic IP gesichert ab und kann nicht manipuliert werden. Im Betrieb sind alle Funkpakete stets verschlüsselt und authentisiert. Ein Mitlesen, Erfinden, Verändern oder Wiederholen von Daten ist ausgeschlossen. Ähnlich wie beim Online Banking werden die universell anerkannten Verfahren AES-128 und CCM eingesetzt.

Das Zitat finde ich ja auch sehr interessant. Soweit ich weiß senden ja heutzutage nur wenige Homematic Komponenten verschlüsselt (z.B. Winmatic, Keymatic). In Zukunft soll das ganze wohl auf Sicherheit fokussiert werden. Aktuell können ja auch Nachrichten "Mitgehört" werden, selbst wenn man das Device nicht gepairt hat, das wird wohl nicht mehr gehen. Hört sich ja prinzipiell gut an.

Ich frage mich, ob nach und nach alle aktuell vertriebenen Homematic Komponenten mit der Zeit gegen Homematic IP ersetzt werden, oder ob die Systeme parallel verkauft werden.

ZitatSicher durch AES-Authentifizierung

angeblich ist es doch schon sicher. nach meinem verständnis ist sicher nicht steigerungsfähig.
eventuell soll nicht mehr jeder mitlesen. wohl nur noch ausgesuchte nachrichtendienste.  ;)

Bei der Fußbodenheizungsfraktion tut sich auch etwas...

http://www.pressebox.de/pressemitteilung/eq-3-ag/Integration-von-Smart-Home-und-Fussbodenheizungsloesungen-auf-der-Basis-von-Homematic-IP/boxid/730063

Interessante Sache, aber bei einer trägen Fussbodenheizung hat man kaum Regelbedarf, sofern sie sauber eingestellt/abgeglichen ist.

Gut ist doch schon mal das es WLAN Gateway geben wird, das spricht schon mal für eine mögliche FHEM Integration (sei denn es ist eine Lösung wie bei RWE über eq3 Server, was ja auch erwähnt wird und das Ding nicht an eine CCU kommt). Die Geräte scheinen schon etwas einfacher zu sein. Ich denke aber schon das das neue Funkprotokoll irgendwann Homematic ersetzten wird. eine Verschlüsselung der Funksingnale ist einfach sinnvoll.
Damit dürfte das ähnlich wie bei RWE Smarthome sein. Ich denke aber das CUL und CUNO da erstmal raus sein dürften.

Interessant finde ich das, dass Wandthermostat eine Hintergrundbeleuchtung kommt. Bei den bisherigen war angeblich die Batterieleistung zu schlapp...... da muss das neue Funkprotokoll ja wahnsinnig Stromsparend sein.

Auf die Preise bin ich auch noch gespannt und ich vermute Bausätze wird es auch nicht geben.

Da wird ganz offensichtlich eine cloud-Lösung realisiert. Ich hoffe, es geht auch ohne, den sonst sind die Teile (zumindest für mich) komplett unbrauchbar.

Zitat von: Mathea am 10 März 2015, 13:50:18
Ich finde die Optik auch zeitgemäßer als die aktuellen Homematik Komponenten.

Ich habe die Teile heute "in echt" gesehen und finde die Optik einfach Kacke haarsträubend (gut, dass ich kaum noch Haare habe)

(http://up.picr.de/21331002pd.jpg)

Alleine schon der Farbton - der sieht aus, als hätte man weisse Komponenten die letzten fünf Jahre in Helmut Schmidts Wohnung getestet.

Ich fand die anderen auch wesentlich schöner.
Schaden, ich habe den Eindrück, dass HM läuft technisch und designtechnisch in die "falsche" Richtung.

Schade, dass sich die Steckdose nicht in einen Rahmen integrieren lässt, auf der eq3 HomePage sah es Optisch so aus.
Mal schauen wie es um die FHEM Integration steht.
Kennt jemand einen genauen Termin zum Verkaufsstart?


Gesendet von iPhone mit Tapatalk

Dann hab ich mit dem Photos quasi den Beweis meiner Vermutung gefunden, als ich bei den Steckdosen "Einfache Montage: schnell und ohne Werkzeug montiert" gelesen habe. Die werden wohl einfach in eine vorhandene Steckdose eingesteckt...

Zitat von: Mathea am 10 März 2015, 15:05:04
Das Zitat finde ich ja auch sehr interessant. Soweit ich weiß senden ja heutzutage nur wenige Homematic Komponenten verschlüsselt (z.B. Winmatic, Keymatic).

Senden die verschlüsselt?!? Das wäre mir aber neu, das ist doch alles nur signiert aber nicht verschlüsselt oder?!?

Aber das Design ist ja wirklich sehr "retro" mit den runden Ecken. Aber kein WLAN finde ich wiederum gut. Ich will kein WLAN zu Hause haben, das ist mir alles etwas zu viel Funk und dann noch im 2,4 GHz, da habe ich dann doch auf Dauer ein wenig Angst um meine Gesundheit. Der Mobilfunkt Kram den man so mit sich rumschleppt reicht mir schon ;-) Da sind mir die 868 MHz schon lieber. Aber gut das ist Geschmackssache.

ZitatSenden die verschlüsselt?!? Das wäre mir aber neu, das ist doch alles nur signiert aber nicht verschlüsselt oder?!?

Derzeitige Geräte senden natürlich nicht verschlüsselt, sondern höchstens signiert. Allerdings sprachen sogar die EQ-3 Leute an dem CeBit-Stand von "Verschlüsselung".
War je ein sehr enttäuschender Besuch: Ein hübsche Dame musste eine andere holen, da sie selbst nicht für HM-IP zuständig war, die andere musste einen Kollegen holen, weil sie der technischen Details nicht mächtig war. Der Kollege wollte mir etwas von Verschlüsselung erzählen, bis ich ihn nach dem Unterschied zu Signierung fragte. Der danach geholte "Kollege" wusste zwar Bescheid, hatte aber keine Zeit, weil er bereits "im Gespräch war".
Naja, wir werden sehen...

Hört sich ja alles sehr klasse an,
Bis jetzt habe ich keinen Grund für einen zukünftigen Umstieg...


Gesendet von iPhone mit Tapatalk

Also doch alles beim alten mit IPv6 tauglicher Basis?!?!?

Als einer der Standbetreuer auf der CEBIT auf meine Nachfragen was von FHEM hörte, kam die eindeutige Aussage, Homematic IP ist für Laien gedacht. - Wir sollten bei den bisherigen Produkten bleiben, die wären für unsere Anforderungen besser geeignet.
Darüberhinaus wetterte er auf die Funksteckdose von Fibraro, die würde " abfackeln" - in ein so schickes und formschönes Gehäuse könnte man soviel Schatleistung nicht unterbringen....

Also wenn ich ja mal eine Zwischensteckerlösung interessant und gelungen finde: Seed Bluetooth, vorgestellt in der letzten ct... die passen nebeneinander in eine 45-Grad-Mehrfachsteckdose... und Leistung brandschutztechnisch einwandfrei schalten ist heute keine Frage von Größe mehr...

geht nich Gips nich ...

In der Pressemeldung hat sich das so angehört: "Homematic IP ist die Geräte- und Kommunikations-Plattform für Smart Home-Lösungen, die auch für Software- und Geräteentwickler in Form von Developer Kits, Modulen und Lizenzen offen verfügbar ist."

Meint ihr der neue Home Control Access point ist noch mit den alten Homematic devices kompatibel?

Zitat von: HolyMoly am 19 Juni 2015, 16:24:25
Meint ihr der neue Home Control Access point ist noch mit den alten Homematic devices kompatibel?

Zitat:
Homematic IP wird im Sommer 2015 zuerst als Raumklima-Lösung verfügbar. Homematic IP Geräte können zusammen mit allen Homematic
Geräten mit der Zentrale CCU2 betrieben werden. Die Kompatibilität der Lösungen und eine besonders einfache Integration sind sichergestellt.

"Integration der Homematic-IP-Geräte in die CCU2 ist für das 3. Quartal 2015 geplant." in FHEM wohl schon früher?!   ;)

Zitat von: eisler am 23 Juni 2015, 15:01:25
"Integration der Homematic-IP-Geräte in die CCU2 ist für das 3. Quartal 2015 geplant." in FHEM wohl schon früher?!   ;)

Naja... Das dritte Quartal 2015 beginnt in 8 Tagen... viel früher wird sich auch in FHEM nichts tun. ;-)

Zitat von: Mr. P am 23 Juni 2015, 15:37:41
Naja... Das dritte Quartal 2015 beginnt in 8 Tagen... viel früher wird sich auch in FHEM nichts tun. ;-)

Lieferzeit wohl 2 Wochen... http://www.elv.de/homematic-ip.html

Bei Amazon alles lieferbar. Irgenwer schon mal was rumgetestet?

würde über Amazon nichts bringen, die versenden mit DHL und DHL liefert nicht wirklich aus  ;)

Du hast schon mitbekommen, dass der Poststreik vorbei ist, oder?

Zitat von: volschin am 11 Juli 2015, 22:30:49
Du hast schon mitbekommen, dass der Poststreik vorbei ist, oder?

das habe ich, das hält DHL leider aber nicht von "Nicht-Liefern" ab. Bis die ihren Rückstand abgearbeitet haben dauert es noch einige Wochen.

Also hier liefern se ganz normal aus ;) ohne Verzögerungen und das schon seit Wochen xD^^

Ich habe rein gar nichts vom Streik bemerkt. Amazon Pakete kamen weiterhin am nächsten Tag (auch nicht Prime) und auch bei anderen Dienstleistern gab es keine Probleme.

Zitat von: marvin78 am 16 Juli 2015, 20:46:44
Ich habe rein gar nichts vom Streik bemerkt. Amazon Pakete kamen weiterhin am nächsten Tag (auch nicht Prime) und auch bei anderen Dienstleistern gab es keine Probleme.

und ich warte immer noch auf 3 Lieferungen.

Gibt es schon erste Erkenntnisse bzgl. Homematic IP?
Ich müsste mir noch einige Heizungsthermostate zulegen und ich bin am überlegen ob ich mir die Homematic IP hole oder doch wieder die HM-CC-RT-DN's

Da du schon eine Menge Homematic Zeug hast, würde ich dabei doch kompatibel bleiben und nicht auf den dazu inkompatiblen IP-Kram gehen.

Hallo,

was ist denn der neue Vorteil der Homematic IP ?

Wenn ich die zwischen ein Homematic IP und einem Homematic Heizkörper Thermostat habe, würde ich mich das herkömmliche Homematic Produkt entscheiden da es günstiger ist.

Gruß Christian

Gute Frage! Ich sehe momentan keinen. Über den Home Control Access Point lässt sich das wohl besser über ein Handy steuern. Mesh-Netzwerke ala Zigbee und eine damit verbundene Reichweitenerhöhung sind aber meines Wissens weiterhin nicht vorgesehen.

Hallo
Ist es denn mittlerweile überhaupt möglich die Homematic IP Geräte an FHEM anzulernen? Und wenn ja mit welcher Hardware?

Gesendet von meinem GT-I9300 mit Tapatalk

Dass würde mich auch mal interessieren

Ich möchte mir auch einen neuen Fensterkontakt holen und überlege ob ich nicht gleich die HM IP geräte kaufe.

Auf Infos wäre ich sehr gespannt?
Preislich liegen die Alten und Neuem gleichen auf.

Zitat von: Freddy am 06 Oktober 2015, 22:55:32
Ich möchte mir auch einen neuen Fensterkontakt holen und überlege ob ich nicht gleich die HM IP geräte kaufe.

Auf Infos wäre ich sehr gespannt?
Preislich liegen die Alten und Neuem gleichen auf.

Ich würde sagen, da muss irgendwer einmal ins kalte Wasser springen und sich irgendein Teil besorgen und dann die notwendigen Daten hier im Forum bereit stellen.
Wenn alle nur warten, werden alle noch recht lange warten. ;-)

Zitat von: Mr. P am 07 Oktober 2015, 08:51:33
Ich würde sagen, da muss irgendwer einmal ins kalte Wasser springen und sich irgendein Teil besorgen und dann die notwendigen Daten hier im Forum bereit stellen.
Wenn alle nur warten, werden alle noch recht lange warten. ;-)

Dann meine doofe Frage, als jemand der nicht viel Ahnung hat. Welche Daten werden denn benötigt? :)

As usual die Rohdaten der Logs.
Wie das geht... siehe hier (http://forum.fhem.de/index.php/topic,16563.0.html). ;-)

Aufgrund der Tatsache dass ich mich erst lange in die Thematik einarbeiten müsste und diese Zeit bis zum Jahresende aus beruflichen Gründen nicht aufbringen kann, könnte ich mir auch vorstellen mich an eine gewisse Art von CrowdFunding zu beteiligen um die Anbindung der neuen IP Serie an FHEM voranzutreiben.

Immerhin profitiere ich davon, möchte aber auch nicht alle Last und Kosten auf einzelne abwälzen. Zumindest bei den Kosten könnte ich meinen Beitrag leisten.

nur ein Vorschlag...

Am besten einmal mit Martin sprechen.
Sofern er Zeit und Lust hat, sind solche Dinge bei ihm zur Analyse am besten aufgehoben. ;-)

Nach der Beschreibung ist hmip immer verschlüsselt. Man kann also eine zentrale nutzen und diese an fhem anbinden oder versuchen alles selbst zu dekodieren.
Ist die Verschlüsselung schon bekannt?

ZitatHöchste Sicherheit
Bereits während der Installation des Systems läuft die Kommunikation von Homematic IP gesichert ab und kann nicht manipuliert werden. Im Betrieb sind alle Funkpakete stets verschlüsselt und authentisiert. Ein Mitlesen, Erfinden, Verändern oder Wiederholen von Daten ist ausgeschlossen. Ähnlich wie beim Online Banking werden die universell anerkannten Verfahren AES-128 und CCM eingesetzt.

http://www.eq-3.de/newsreader/items/homematic-ip-das-smart-home-spricht-jetzt-ipv6.html

Gesendet von meinem Nexus 5 mit Tapatalk

Demnach können die Kompenenten nur über die "Homematic IP Access Point" oder "CCU2" betrieben werden? Auf die CCU2 würde ich gerne verzichten, den "Homematic IP Access Point" könnte ich mir durchaus vorstellen. Mit dem Smartphone kann man auf den "Homematic IP Access Point" zugreifen, ich denke mal via WLAN bzw. via WLAN über den Router und dann weiter mit LAN zum Access Point.

Solte sich das Sicherheitskonzept als ShowStopper erweisen, könnte man sich doch überlegen ob man eine Anbindung über den Access Point ermöglichen kann. Ich selber denke eh über einen zusätzlichen (zum CUL) Access Point nach um eine höhere Reichweite und eine bessere Empfangsqualität zu erreichen. Da der "Homematic IP Access Point" durchaus Wohnzimmer-Qualität hat wäre dass eine durchaus akzeptable Möglichkeit.

Gruß!
_____________________________________________

Nachtrag: Die Anbindung der Mobiltelefone erfolgt über die HomeMatic Cloud...

Homematic IP Access Point

Verbindet das Smartphone über die Homematic IP Cloud mit den Homematic IP Geräten

Wäre für mich ein ShowStoper, da meine Mobilgeräte nur über VPN ins lokale Netzwerk gehen. D.h., wenn schon eine Cloud, dann bei mir im Keller.

ZitatWäre für mich ein ShowStoper, da meine Mobilgeräte nur über VPN ins lokale Netzwerk gehen. D.h., wenn schon eine Cloud, dann bei mir im Keller.

Sehe ich genau so!



Gesendet von meinem Nexus 5 mit Tapatalk

Ich habe mir zum Access Point mal die Bedienungsanleitung angesehen, allem Anschein geht es da nur über die HomeMatic Cloud:

• Der Access Point wird am Server registriert.
Dies kann einige Minuten dauern. Bitte warten
Sie.
• Bei erfolgreicher Registrierung drücken Sie die
Systemtaste Ihres Access Points zur Bestätigung.
• Das Anlernen wird durchgeführt.
• Der Access Point ist nun eingerichtet und so
fort einsatzbereit.

Kein Wort über ein Web-Frontend, demnach fällt für mich diese Komponente flach.

Die HueBridge hat auch kein Webfrontend und lässt sich trotzdem lokal steuern. Das sagt also erstmal noch gar nichts. Wenn allerdings keine API offengelegt ist, wird das schwierig, wenn nicht unmöglich bei vorhandener Verschlüsselung. Man müsste dann mit Man-in-the-middle arbeiten und wenn das Serverzertifikat im Client eingebaut ist, wird es fast unmöglich. Keine Ahnung, ob eq3 mittlerweile Software-Entwickler hat, die in punkto Verschlüsselung was von ihrem Job verstehen.  ;)

Wäre für mich ein ShowStoper, da meine Mobilgeräte nur über VPN ins lokale Netzwerk gehen. D.h., wenn schon eine Cloud, dann bei mir im Keller.
[/quote]

...im Keller wär's auch keine Cloud... das macht den BuzzWord-Faktor kaputt  ::)

gibt es hierzu Neuigkeiten?

Hallo! Ich habe eine CCU2 und bin gerade dabei nach FHEM zu migrieren. Die Integration mache ich mit dem HM-CFG-LAN Adapter, die CCU2 wird dann still gelegt. Weiters habe ich etliche "normale" HM Devices, die konnte ich problemlos mit FHEM pairen. Ich habe auch einige "HomeMatic IP" Devices, genauer gesagt ein paar TFKontakte und Schaltsteckdosen. Diese konnte ich an der CCU2 (mit der neuen Firmware) problemlos anlernen. Unter FHEM bekomme ich sie aber nicht gepairt ... irgendwelche Ideen?

Homematic IP an CCU2 anlernen. CCU2 mit FHEM verbinden. Direkt geht es (noch) nicht.

Jetzt musste ich schonwieder Lehrgeld bezahlen, weil ich nicht aufgepasst habe, oder einfach keine Ahnung habe.

Hab mir den Bewegungsmelder bestellt:

http://www.elv.de/homematic-ip-bewegungsmelder-mit-daemmerungssensor-innen-fuer-smart-home-hausautomation.html

Und das "IP" hab ich natürlich nicht gesehen. Gibt es mittlerweile eine Möglichkeit, den mit fhem zu betreiben ?

Nein, geht momentan nur über den Umweg CCU2 mit HMCCU oder HMRPC.

Moin,

was ich nicht verstehe. Braucht man die CCU2 und den Homematic IP Access Point oder reicht die CCU2?

Viele Grüße

Kai

Guten Morgen!

Die CCU2 reicht.

Liebe Grüße,
Max

Ach cool - das ist ja mal ne gute Nachricht.  ;D

Ich betreibe momenten meine HomeMatic Komponenten mittels HM-LAN Adapter. Da ich aber für die Fußbodenheizung auf HomeMatic IP umstellen muss werde ich mir dann auch die CCU2 kaufen müssen. Sind meine "alten" HomeMatic Komponenten (Fenster / Tür Kontakte etc.)  dann über die  CCU2 ansprechbar?

Du kannst auch die CCU2 über FHEM ansprechen. Siehe Modul HMCCU.

Zitat von: bjoernbo am 22 August 2016, 13:04:38
Ich betreibe momenten meine HomeMatic Komponenten mittels HM-LAN Adapter. Da ich aber für die Fußbodenheizung auf HomeMatic IP umstellen muss werde ich mir dann auch die CCU2 kaufen müssen. Sind meine "alten" HomeMatic Komponenten (Fenster / Tür Kontakte etc.)  dann über die  CCU2 ansprechbar?

Die CCU2 unterstützt BidCos-RF (also die alten Komponenten), Wired und HM-IP.

Wird die "alte" HM-Produktschiene weiterbetrieben?
Wie wahrscheinlich ist es dass CosIP auch unter FHEM mit dem HMLAN funktionieren wird?
Ich bin aufgrund der breiten Produktpalette auf HM gegangen. Wenn die sich nun nach außen abschotten wäre das unschön.

Bisher ist bei EQ-3 nicht erkennbar, dass die alte Welt eingestellt werden soll. Für einen Fortbestand spricht auch die viel größere Menge an Komponenten.

Grundsätzlich scheint EQ-3 HMIP zu lizenzieren, da z.B. Qivicon seit neuestem HMIP unterstützt. Die müssen die Specs irgendwie von EQ-3 bekommen haben. Das Protokoll basiert auf ipv6 und ist komplett verschlüsselt. Ohne EQ-3 Hilfe wird da nix gehen.

Nabend,

aber es ist doch trotzdem noch 868 MHz oder? Aber basiert auf IPv6? Da muss der doch wahnsinnig viele Daten verschicken oder? Kann ich mir ja bald garnicht vorstellen.

Bis jetzt dachte ich immer das neue Gateway bildet in einer Richtung IPv6 ab und in die andere Richtung ist es normales BidCos. So das von außen eben jedes BidCos Gerät eine IPv6 Adresse hat, oder irgendwie so. Aber gut das waren nur meine Gedanken. Leider findet man ja nirgends Informationen dazu, alles nur so schwammiges Sales Gesülze. :-( Oder hat da schon jemand irgendwo ein blueprint gefunden?

/Daniel

Ist immer noch 868 MHz Technik. Als Protokoll wird aber IPv6 verwendet. Du musst zwischen Übertragungsmedium (WLAN wäre z.B. ein solches) und Protokoll unterscheiden. bidCos ist ein Protokoll und tcp bzw ip eben auch.

Das bedeutet nicht zwingend, dass da mehr  Daten übertragen werden.

Wenn man sich nicht extra eine CCU2 für HMIP kaufen möchte, kann man sich einen Raspi Software mäßig zur CCU aufrüsten und ihn dann per HMCCU mit FHEM verbinden.

Zitat von: zap am 06 September 2016, 07:52:04
Das bedeutet nicht zwingend, dass da mehr  Daten übertragen werden.

OK, wenn du meinst ;-)

Hallo!

Hat denn schon jemand HM und HMIP in friedlicher Koexistenz am Laufen?
Einige der Komponenten finde ich schon ganz nett, aber Homematic bietet einfach Dinge, die ich sonst nirgends finden kann.

Grüße
Phil

Ja, habe 2 HMIP Steckdosen im Einsatz und jede Menge BidCos Komponenten. Beides an einer CCU2. Läuft.

Läuft das eigentlich auch an einem HMLAN Adapter der als Range Extender an einer CCU2 angemeldet ist?

/Daniel

Weiß ich nicht. Allerdings musste bei der CCU2 die Firmware aktualisiert werden für die HMIP Unterstützung. Da mir für den HM-LAN Adapter kein entsprechendes Update bekannt ist, vermute ich mal, dass das nicht funktioniert.

Hallo,

Gibt es hierzu was neues. Es gibt demnächst einen neuen Fussbodenheizungsaktor in 6 und 10er Ausführung.

Wäre Interessant wenn man das ganze in fhem steuern könnte.


Fußbodenheizungsaktor – 6-/10-fach, 24 V

Artikel-Nr.: 143237A0/143238A0


Gruss

Zitat von: zap am 06 September 2016, 14:21:02
Weiß ich nicht. Allerdings musste bei der CCU2 die Firmware aktualisiert werden für die HMIP Unterstützung. Da mir für den HM-LAN Adapter kein entsprechendes Update bekannt ist, vermute ich mal, dass das nicht funktioniert.

Es gibt ein Update für den HMLAN auf Version 0.965, damit er bei einem Empfang von HMIP-Frames nicht abstürzt.

Zur Klarstellung: Der HMLAN unterstützt keine Homematic-IP-Komponenten, er braucht aber für seine "normale" Funktion mit den Standard-Homematic-Komponenten das Update, falls irgendwo ein Homematic-IP-Paket auftauchen kann.

@lewej: Nach aktuellem Stand und bis auf weiteres wird fhem nur über die CCU2 mit den Modulen HMRPC oder HMCCU Homematic-IP-Komponenten unterstützen.

Zitat von: Ralli am 26 September 2016, 17:35:09
Es gibt ein Update für den HMLAN auf Version 0.965, damit er bei einem Empfang von HMIP-Frames nicht abstürzt.

Zur Klarstellung: Der HMLAN unterstützt keine Homematic-IP-Komponenten, er braucht aber für seine "normale" Funktion mit den Standard-Homematic-Komponenten das Update, falls irgendwo ein Homematic-IP-Paket auftauchen kann.

@lewej: Nach aktuellem Stand und bis auf weiteres wird fhem nur über die CCU2 mit den Modulen HMRPC oder HMCCU Homematic-IP-Komponenten unterstützen.

Hallo,

Ich betreibe das mit dem hmland und hm-cfg-usb, ist da was in Planung?

Gruss

Kurze Zwischenfrage zu diesem Thema, ich habe das ganze etwas verschlafen:

Ich verwende einen HMLAN und diverse Homematic Geraete (Thermostate, Steckdosen/Verbrauchsmessung, Dimmer, usw).
Ist es moeglich da Homematic IP Geraete einzubinden oder brauchts da noch was zusaetzliches?
(Habe gesehen die Homematic IP Verbrauchssteckdosen sind kleiner und guenstiger als die alten).

Danke,
Christoph

Du hast offenbar auch die zahlreichen Wortmeldungen dazu verschlafen und nicht einmal die Beiträge in diesem Thread gelesen. Anders kann ich mir nicht erklären, warum Du diese Frage hier stellst... sorry, aber ein Mindestmaß an persönlicher Vorarbeit muss man  voraussetzen dürfen.

geht nich gips nich

Zitat von: Pfriemler am 08 Dezember 2016, 12:12:50
und nicht einmal die Beiträge in diesem Thread gelesen.

ein, bzw. 2 Beiträge weiter oben hätte ja schon gereicht.

Hallo zusammen,

ich habe FHEM auf einem BananaPi mit ein paar Thermometer/Hygrometer im Einsatz und wollte das schon länger mal ausbauen. Nun habe ich etwas Zeit und ein paar Dinge geplant. Unter anderem wollte ich Thermostate und Fensterkontakte aber auch ein Türschlossantrieb hinzufügen. Nun gibt es ja einiges schon als Homematic IP und mir stellt sich die Frage, ob ich nicht auf diese Komponenten zurückgreifen soll. So richtig herausfinden zum Thema Unterschied der beiden Paletten lässt sich kaum etwas... Habe ich da etwas übersehen?

Ansonsten habe ich den Thread durchgelesen und es scheint, als hätten ein paar die neuen Komponenten bereits über die CCU2 an FHEM angedockt. Was ich nicht finden konnte, war eine Liste an Anforderungen, um das Andocken zu ermöglichen. Auch hier noch mal kurz die Frage: habe ich so etwas übersehen? Könnte alternativ jemand so etwas erstellen oder Tipps geben? Wichtig wäre mir vor allem zu erfahren, welche Teile ich kaufen muss um zu schauen, welche Kosten entstehen.

Edit: nach erneutem Durchlesen meiner Fragen scheinen die etwas unklar zu sein: "CCU2 mit den Modulen HMRPC oder HMCCU" gab es bereits als Antwort und eigentlich habe ich genau dazu spezifische Anfragen (es ist wohl zu spät für mich):
* CCU2 wäre das hier: http://www.eq-3.de/produkte/homematic/zentralen-und-gateways/homematic-zentrale-ccu-2.html
* HMRPC: ist die Software https://github.com/henryk/fhem-HMRPC gemeint? Gibt es da was aktuelleres?
* HMCCU ist wohl https://wiki.fhem.de/wiki/HMCCU, was ich von hier bekommen könnte: https://github.com/mhop/fhem-mirror/tree/master/fhem/contrib/HMCCU (oder checkout via SVN).

Die CCU2 funkt dann zu den einzelnen Geräten und ist mit dem (W)LAN verbunden, worüber dann mein FHEM mit der CCU2 kommuniziert.

Soweit korrekt? Fehlt noch etwas?

Wenn ich jetzt noch wüsste, was sich beim Thema Verschlüsselung/Sicherheit getan hat, könnte ich beide Varianten (Homematic und Homematic IP) mal vergleichen und anhand dessen entscheiden, welche Produkte ich wähle. Schließlich ist ja auch die Kommunikation zwischen FHEM und Gerät verschlüsselt, wenn ich das richtig gelesen habe.

Vielen Dank für eure Antworten,
  Matthias

P.S.:
• Zwar ist das mein erster Beitrag, allerdings ist wohl weil mein Benutzerkonto gelöscht worden. Mein bisheriger Login hatte nicht mehr funktioniert.
• Ich habe die Suchfunktion genutzt aber nichts gefunden. Der Thread erschien mir zu meinen Fragen passend. Ich schätze, thematisch passt das als Antwort hier besser denn als neuer Thread.

Zitat von: rainboxx am 11 Dezember 2016, 23:23:04
* HMCCU ist wohl https://wiki.fhem.de/wiki/HMCCU, was ich von hier bekommen könnte: https://github.com/mhop/fhem-mirror/tree/master/fhem/contrib/HMCCU (oder checkout via SVN).

Nein, HMCCU ist mittlerweile Teil der FHEM Distribution. Wenn Du regelmäßig Updates machst, sollte das auf Deinem Rechner schon drauf sein, d.h. unter /opt/fhem/FHEM bzw. Deinem Modulverzeichnis findest du 88_HMCCU.pm, 88_HMCCUDEV.pm und 88_HMCCUCHN.pm.

Zitat
Die CCU2 funkt dann zu den einzelnen Geräten und ist mit dem (W)LAN verbunden, worüber dann mein FHEM mit der CCU2 kommuniziert.

Soweit korrekt? Fehlt noch etwas?

Ja das ist so korrekt.

Zitat
Wenn ich jetzt noch wüsste, was sich beim Thema Verschlüsselung/Sicherheit getan hat, könnte ich beide Varianten (Homematic und Homematic IP) mal vergleichen und anhand dessen entscheiden, welche Produkte ich wähle. Schließlich ist ja auch die Kommunikation zwischen FHEM und Gerät verschlüsselt, wenn ich das richtig gelesen habe.

Verschlüsselung ist relativ, gerade bei Homematic-Alt. HMIP nutzt für die Kommunikation IPv6 mit Verschlüsselung. Das ist auch der Grund, weshalb man das nicht direkt in FHEM einbinden kann, nur über den Umweg CCU2.

HM-IP:
* Biisher nur wenige Komponenten
* Verschlüsselt
* Nicht direkt in FHEM integrierbar
* Komponenten sehen besser aus (rein subjektiv)
* Gefühl mehr Drive in der Entwicklung seitens EQ3 (z.B. Fußbodenheizungssteuerung)

HM BidCos (alt):
* Sehr viele Komponenten am Markt verfügbar
* Nicht wirklich verschlüsselt
* Direkt in FHEM integrierbar (CUL_HM)
* Komponenten Design etwas "oldschool"
* Es kommen immer noch neue Komponenten auf den Markt. EQ-3 scheint das also parallel zu HM-IP zu fahren

Zitat von: zap am 12 Dezember 2016, 07:41:32

* Komponenten Design etwas "oldschool"

Das ist aber kein Nachteil zu HMIP. Die Dinger sind weder moderner noch schöner ;)

Hallo,

die CCU Software kann ja auf einem RPI laufen - mit einem MOD-RPI. Kann der RPI dann etwas mit HM-IP Geräten was anfangen, oder ist dieser Teil noch nicht implementiert. Der RPI und MOD-RPI ist deutlich günstiger als einen CCU2.

Gruß Christoph

Zitat von: Bennemannc am 20 Dezember 2016, 17:23:29
... CCU Software kann ja auf einem RPI laufen - mit einem MOD-RPI. Kann der RPI dann etwas mit HM-IP Geräten was anfangen, oder ist dieser Teil noch nicht implementiert.

Nach allem was ich weiß, geht das leider nicht, an der CCU2 führt aktuell kein Weg vorbei. M.W. ist die spezielle HMIP-Verschlüsselung nicht im OCCU & Co enthalten.
RPI+HMUART+Speicherkarte+Gehäuse+Netzteil vs. CCU2 als ARR-Bausatz ... hm, so groß ist der Unterschied dann auch nicht mehr...
Wird wohl bei mir früher oder später wieder eine werden ...

Evtl. wäre auch der Bausatz für 80€ eine Alternative. M.W. ohne bzw. mit wenig Löten.

Zitat von: zap am 21 Dezember 2016, 07:39:34
Evtl. wäre auch der Bausatz für 80€ eine Alternative. M.W. ohne bzw. mit wenig Löten.

Meines Wissens ohne. ARR eben. Das meinte ich ja auch im Vergleich mit den Kosten für Raspi etc.

Mich bewegt immer noch die Frage, ob ich die CCU parallel zu FHEM auf dem gleichen Raspi zum Laufen bekomme ...

Hm, also wenn ich noch ein bisschen mehr im Netz suche, finde ich das "Homematic Open-Central-Control-Unit-Software-Development-Kit" und ein "Funkmodul" (http://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html) dazu. Das scheint aber eher nur das Funkmodul zu sein ohne integrierte Verschlüsselung.

Schaue ich aber hier: http://homematic-forum.de/forum/viewtopic.php?t=34497 gibt es ein RaspberryMatic, was scheinbar die komplette CCU2 imitiert.

Scheint also grundsätzlich möglich zu sein. Nur, die Kosten für die CCU2 als Bausatz unterschreiten wohl die Kosten für Raspberry inkl. Antenne etc., Virtualisierung ist wohl auch nicht ganz so einfach. Und wenn ich das richtig gesehen habe, kann man die CCU2 auch in FHEM einbinden, oder?

Hm...

Ja, siehe mein Beitrag oben auf dieser Seite bzw. den Wiki Artikel HMCCU

Also wenn ich mir eine CCU2 anlege, dann kann ich die IP Serie auch bei FHEM einbinden?

Bisher habe ich ja alles über meinen kleinen LAN Adapter laufen, aber alleine nur wegen der Größe der Steckdosen wäre es zu überlegen, wenn man sich im Gegensatz die Monster Steckdosen der normalen Homematic Reihe anguckt.

Die Innensensoren (Temp usw.) sind in der IP Serie auch günstiger als in der Originalserie (30 statt 50 Euro)

Zitat aus der Beschreibung von ELV:

ZitatÜber die Homematic Zentrale CCU2 lässt sich zudem eine direkte Brücke zu den Komponenten des Homematic Systems schlagen, so dass das Homematic IP System somit auch offen für Erweiterungen mit den über 80 Komponenten der Homematic Familie ist.

Kann man dann auch die Heizungsthermostate der Originalserie mit denen der Homaticserie koppeln?

Das Modul HMCCU unterstützt HMIP Komponenten in Verbindung mit einer CCU2.

M.W. kann man aber ein bidCos Thermostat nicht mit einem HMIP Thermostaten direkt koppeln. Das geht nur über den Umweg HomeMatic Script CCU Programm oder über FHEM

Hallo zusammen,

ich wollte mir gerade Bewegungsmelder zulegen und habe die HMIP-SMO-A entdeckt.

Zurzeit nutze ich einen HMLAN zur Steuerung von unseren Jalousien über FHEM.

Wenn ich jetzt noch zusätzlich eine CCU2 kaufen würde, um die HMIP-SMO-A zu betreiben, könnte ich über das Modul HMCCU auf notify's (Bewegung) reagieren und über FHEM Strahler steuern?
Würde dann die CCU2 mit HMLAN reichen, um die HMIP-SMO-A einzubinden oder benötige ich noch andere Komponenten?

Viele Grüße
Marc

Das sollte in der Konstellation funktionieren. Alternativ zur CCU kannst du auch einen Raspi mit Zusatzmodul ausstatten und die CCU Spftware darauf installieren. Einfacher dürfte es aber mit einer CCU sein.
Kaufe den Bausatz. Der ist billiger und kann ohne Löten zusammengeschraubt werden.

Danke, habe gerade die Bestellung abgeschickt. Werde es dann testen und hier berichten...

Trotz suche und lesen hier im Forum und FHEM Wiki ist es mir noch nicht ganz klar, was nun geht.
Gelesen habe ich zu HMIP im Wiki"Somit sind die Geräte aktuell nur über eine systemeigene Zentrale CCU2 (als physisch vorhandenes Interface) und die HomeMatic-Module in FHEM integrierbar"
Bei ELV beschreibung zu Homematik-IO "kurz HM-OCCU-SDK, eine alternative Plattform zur Homematic Zentrale CCU2."

Ich habe einen HMLAN und ein HMUARTLGW in meiner VCCU und würde gerne eine HMIP Schaltsteckdose steuern.

Ist das mit dem HMUARTLGW und HMCCU möglich?

Meine HMLAN scheint bei Empfang des Pairings in den Reboot zu gehen -> FW update nötig.

Ich möchte keine HMCCU2 oder das Internetgateway kaufen.

Zitat von: elo am 02 August 2017, 10:50:38
Ich möchte keine HMCCU2 oder das Internetgateway kaufen.

Ohne CCU2 (oder vglbar: Raspimatic evtl. oder "Selbstbau-CCU2") wird es nicht gehen.

Weil:

HMCCU <-> CCU2 <-> HMIP-Gerät

Und aktuell kann nur eine CCU2 (und vglbar) mit HMIP-Geräten kommunizieren.

Gruß, Joachim

Homematik-IO/HMUARTLGW "kurz HM-OCCU-SDK, eine alternative Plattform zur Homematic Zentrale CCU2."

kann also keine CCU2 ersetzen, weil?

Doch, wie geschrieben:

entweder echte CCU2 oder vglbar (Raspimatic [falls dort HMIP mittlerweile unterstützt] oder "selbstbau CCU2" [SDK, ODK wie immer das heißt).

Aber es braucht eine extra HW!

Also nicht:

fhem plus HMLAN/HMUARTLGW/... und dort dann auch CCU2

Sondern entweder:

HM-MOD-PCB (Funkmodulaufstecker für PI) plus PI und CCU2 Software (wie/welche auch immer) oder halt echte CCU2

und dann alle Homematic-Geräte (inkl. HMIP) dort anlernen/verwalten etc. und per HMCCU in fhem einbinden.

oder halt 2 HM-IODev. Eines an fhem und dort direkt sie HM-Geräte (ohne IP) und per CCU2 und HMCCU "nur" die HMIP-Geräte (aber die Mischung würde ich nicht machen).

Gruß, Joachim

Danke Joachim, mein Knoten löst sich langsam....

Also ich habe auf meinem PI ein HM-MOD-PCB, dieser ist im FHEM ein HMUARTLGW. Dort habe ich das coprocessor_update.eq3 geflashed, dieses Teil sollte also alle EQ3 Homematic Protokolle können und sich zur CCU2 nur über die Art des Anschlusses unterscheiden. (LAN <-> seriell) Richtig?

Ich nutze den HMUARTLGW bereits in einer VCCU mit einem HMLAN und steuere div. Homematic Komponenten (nicht IP).
Angelernt sind meine Komponenten in FHEM/VCCU nicht am HMUARTLGW im speziellen, also nicht so, als hätte ich eine CCU2 und würde diese über FHEM verwalten/steuern.

Was ich nicht habe ist eine CCU2 Software/SDK welche den HM-MOD-PCB direkt steuert und eine Schnittstelle für FHEM bietet welche dann wiederum von HMCCU verwaltet wird.

Also aktuell keine Möglichkeit Homepatic IP zu nutzen?

Gruß Eike

Zitat von: elo am 02 August 2017, 13:31:31
Danke Joachim, mein Knoten löst sich langsam....

Hallo Eike,

bitte gerne!

Zitat von: elo am 02 August 2017, 13:31:31
Also ich habe auf meinem PI ein HM-MOD-PCB, dieser ist im FHEM ein HMUARTLGW. Dort habe ich das coprocessor_update.eq3 geflashed, dieses Teil sollte also alle EQ3 Homematic Protokolle können und sich zur CCU2 nur über die Art des Anschlusses unterscheiden. (LAN <-> seriell) Richtig?

Nein!
Also nicht ganz.
So wie ich es verstanden habe:

das aktuelle HM-Protokoll wird durch den HMUART etc. abgefahren, inkl. ACK etc.
Aber schon der Signaturschlüssel kommt von fhem (bzw. vccu), also von einer Software die das Funkmodul nutzt...

Die "neue" Kommunikation (verschlüsselt etc.) für HMIP kommt (zu großen Teilen/komplett) durch die verwendende Software, also CCU2.
Da dieser Teil nicht "offen" ist, kann das auch durch fhem (etc.) nicht "nachgebaut werden.
Daher: für HMIP ist eine CCU2 (oder vglbar. siehe Posts zuvor) notwendig!

Zitat von: elo am 02 August 2017, 13:31:31
Ich nutze den HMUARTLGW bereits in einer VCCU mit einem HMLAN und steuere div. Homematic Komponenten (nicht IP).
Angelernt sind meine Komponenten in FHEM/VCCU nicht am HMUARTLGW im speziellen, also nicht so, als hätte ich eine CCU2 und würde diese über FHEM verwalten/steuern.

Es wird nie an ein Funkmodul (egal welches) "angelernt" sondern immer an eine Zentrale.
Entscheidend ist die HMID!

Zitat von: elo am 02 August 2017, 13:31:31
Was ich nicht habe ist eine CCU2 Software/SDK welche den HM-MOD-PCB direkt steuert und eine Schnittstelle für FHEM bietet welche dann wiederum von HMCCU verwaltet wird.

Also aktuell keine Möglichkeit Homepatic IP zu nutzen?

Richtig!
So gibt es (aktuell) keine Möglichkeit HMIP zu nutzen!

Gruß, Joachim

Die RaspberryMatic Jungs nutzen eine OCCU https://github.com/eq-3/occu und können scheinbar HMIP, ist da ein Firmware "blob/closed source" drin?

findest du dort für alle dateien den source code?

Zitat von: MadMax-FHEM am 02 August 2017, 12:48:43
Aber es braucht eine extra HW!

Hier (https://forum.fhem.de/index.php/topic,71757.msg634967.html#msg634967) hat chris1284 eine Anleitung gepostet, mit der es auf derselben Hardware ginge.

Leider scheinen in dem OCCU-repo tendenziell nur binaries zu liegen.

Gruß, Beta-User

Zitat von: frank am 02 August 2017, 14:04:13
findest du dort für alle dateien den source code?

Ich komme ca. alle 6-12 Monate, meistens durch eine Erweiterung meiner FHEM Installation, dazu mich in diese Materie einzulesen. Dabei stolpert man über vieles Neues und Geändertes.
In diesem Fall zum ersten mal mit HMIP. Bisher sind alle Projekte mit denen ich zu tun hatte auf github opensource. (mapcrafter, mcdungeon, etc.)
Wenn ich jetzt in das Projekt schaue, sind die einzigen Dateien die Blobs sein könnten, jar Dateien und selbst die kann man entpacken. Keine Ahnung ob es kompiliertes Java gibt.
Also würde ich auf Deine Frage, obwohl Du die Antwort zu kennen scheinst, ein JA antworten.

Zitat von: Beta-User am 02 August 2017, 14:26:24
Hier (https://forum.fhem.de/index.php/topic,71757.msg634967.html#msg634967) hat chris1284 eine Anleitung gepostet, mit der es auf derselben Hardware ginge.

Ah, ok, danke!

Wieder was gelernt...

Gruß, Joachim

Hi,

so wie ich das bisher verstanden habe, kann ich mit der CCU2 die HM-IP Geräte in FHEM nutzen und ansprechen. Kann ich denn auch parallel eine EQ3-AG HMIP-HAP mit den gleichen Geräten nutzen?

Der Hintergrund: Ich will die originale Software von Homematic nutzen um die Geräte zu steuern und FHEM nur dazu nutzen um einige Energiedaten auszuwerten.

Gruß hansemann

Ich fürchte nicht da es dann 2 zentralen gäbe und du nur eine an die aktoren  anlernen kannst.
Was meinst du mit originaler Software (wahrscheinlich die App da du vom hmip ansprichst)?

Zitat von: MadMax-FHEM am 02 August 2017, 11:38:33
Ohne CCU2 (oder vglbar: Raspimatic evtl. oder "Selbstbau-CCU2") wird es nicht gehen.

Weil:

HMCCU <-> CCU2 <-> HMIP-Gerät

Und aktuell kann nur eine CCU2 (und vglbar) mit HMIP-Geräten kommunizieren.

Gruß, Joachim

Hallo Joachim,

der hm-mod-rpi-pcb ist ein vergleichbarer CCU2, oder? Somit sollte ich die IP-Geräte einbinden können, oder?

Ich hatte vorher einen HMLAN. Diesen hab ich jetzt durch den Bausatz hm-mod-rpi-pcb und das Modul HMUARTLGW ersetzt.
Mit den alten Geräten funktioniert alles super. Hier mal meine Konfig:


define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId AAAAAA

define vccu CUL_HM AAAAAA
attr vccu IODev myHmUART
attr vccu IOList myHmUART
attr vccu model CCU-FHEM
attr vccu subType virtual

define ActionDetector CUL_HM 000000
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

define wz_Rollo_Links CUL_HM ABCDEF
attr wz_Rollo_Links IODev myHmUART
attr wz_Rollo_Links IOgrp vccu:myHmUART
attr wz_Rollo_Links autoReadReg 4_reqStatus
attr wz_Rollo_Links event-on-change-reading pct
attr wz_Rollo_Links expert 2_full
attr wz_Rollo_Links firmware 2.3
attr wz_Rollo_Links model HM-LC-Bl1PBU-FM
attr wz_Rollo_Links peerIDs 00000000,
attr wz_Rollo_Links serialNr LEQxxxxxxxx


Ich bekomme aber meine neuen IP-Geräte nicht mit FHEM gepaired:
4 x HMIP-WTH und 1 x HmIP-FAL230-C10

Wenn ich in FHEM folgenden Befehl absetze
set myHmUART  hmPairForSec 600
und eines der Geräte in den pairing-Modus versetze, ändert sich nichts im FHEM.

Funktioniert dies überhaupt? Wenn ja, gibt es hier irgendwo eine Beschreibung oder hat wer einen Tipp?

Danke schon mal.

Viele Grüße

Die IP Geräte funktionieren generell nicht direkt mit FHEM. Das geht nur mit Umweg über die CCU2 so wie ich das verstanden habe.

Warum auch immer. Die IP Geräte nutzen wohl anstelle der Signierung jetzt eine Verschlüsselung. Um die Geräte mit FHEM anzusprechen bräuchte man also den verwendeten Schlüssel/Passphrase/Key wie auch immer man das nennt, und das wird vermutlich das Problem sein. Aber das ist nur eine Vermutung.

/Daniel

@Fischei: du verwechselst Funk Hardware mit Funk Software. HM-IP ist ein neues, verschlüsseltes Protokoll auf IPv6 Basis.

Du kannst auf dem Raspi eine CCU2 quasi in Software emulieren. Die Software dazu liefert EQ-3. Mit dem Modul HMCCU kannst Du dann über den Umweg CCU2-Software die HMIP Geräte ansprechen.

@Fischei: YAHM installieren (wenn du nur einen pi hast) oder raspberrymatic (wenn du einen extra pi nehmen willst) und das hm-mod-rpi-pcb statt in fhem dort für die virtuelle ccu2 nutzen. nur so kannst du ohne ccu2 kauf hmip mit fhem betreiben (über die hmccu module)

danke euch alle. jetzt funktioniert es. hab mich zwar jetzt drei Tage damit gespielt aber jetzt geht es.
Ein Problem hab ich noch. Wenn ich den Raspberry restarte, dann kommt folgende Meldung:
2017.10.11 11:14:54 1: HMCCU: 500 Can't connect to 192.168.1.105:8181
und somit können die Geräte auch nicht ausgelesen werden.
Wenn ich aber dann FHEM manuell neu starte, dann funktioniert alles.
Hat hier jemand eine Idee? Oder soll ich hier besser mal einen neuen Thread aufmachen?
Für mich hört sich das nicht Timing Problem an.

Zitat von: Fischei am 11 Oktober 2017, 12:07:46
... und somit können die Geräte auch nicht ausgelesen werden.
Wenn ich aber dann FHEM manuell neu starte, dann funktioniert alles.
Hat hier jemand eine Idee? Oder soll ich hier besser mal einen neuen Thread aufmachen?

Ich glaub, dafür gibt es schon diese Diskussion hier (https://forum.fhem.de/index.php/topic,77581.0.html).

Zitat von: Fischei am 11 Oktober 2017, 12:07:46
Für mich hört sich das nicht Timing Problem an.

Ja, ist es. Die CCU Services sind noch nicht gestartet. Das dauert immer 1-2 Minuten.

Ich checke voraussichtlich noch heute ein Update ein. Damit kann man HMCCU dazu veranlassen, beim Define eine bestimmte Zeit auf die CCU zu warten. Das verzögert dann zwar den Start von FHEM entsprechend lange, sollte aber die Probleme beheben.

Super, danke dir! Ich teste es morgen gleich und geb dir bei dem anderen Thread Rückmeldung.

Nabend,

ich hätte jetzt auch ein HM IP Gerät was mich interessieren würde. Da ich nur ein HM-LAN habe (den ganz alten runden), benötige ich jetzt also eine CCU2 oder ein RPi mit diesem HM Aufsteckadapter. Warum wird denn das HM-IP nicht nicht direkt von FHEM unterstützt? So wie ich das verstehe gibt es doch da dieses occu Projekt und dort müsste man doch an die Funktionen kommen um das zu "kopieren" oder was ist das eigentliche Problem? Kann mir das jemand erklären?

Und weiß zufällig jemand ob ich diesen HM Audsteckadapter wirklich brauche oder ob mein HM-LAN Adapter (In Verbindung mit dieser CCU2 Simulation auf dem RPi) auch ausreichen würde für HM-IP Geräte? Trotz des blödsinnigen Namen "IP" ist es doch trotzdem 868 MHz und eine Art BidCos oder wie? Die eigentliche Umsetzung in IP macht doch dieser Access Point und die Wolke, sofern man das nutzt oder?

Irgendwie weiß ich nicht so richtig wie ich das am besten machen soll. Nur wegen einem Gerät jetzt eine extra CCU2 hinstellen und alle anderen "alten" HM Geräte sind direkt an FHEM angelernt ist nicht unbedingt sinnvoll oder?

/Daniel

ZitatUnd weiß zufällig jemand ob ich diesen HM Audsteckadapter wirklich brauche oder ob mein HM-LAN Adapter (In Verbindung mit dieser CCU2 Simulation auf dem RPi) auch ausreichen würde für HM-IP Geräte?

Nö, der kann das nicht. Auch nicht wenn man ihn an einer echten ccu2 als entferntes Gateway nutzen will. Du brauchst ne occu oder ne CCU2 um HM-IP in fhem nutzen zu können.
Das wird sich wohl auch nicht ändern und meiner Meinung nach wird CUL_HM wohl auf lange Sicht von HMCCU abgelöst werden weil gerade das HMIP-Segment sich bisher in eine interessante Richtung entwickelt und Bidcos ehr stagniert

Mhh macht die Sache dann vermutlich nicht einfacher wenn man jedes Gerät mit der CCU koppeln muss und dann wiederum irgendwie jedes einzeln an FHEM durchreichen muss. Dann ist FHEM natürlich überflüssig, zumindest für die die nur HM benutzen und keine anderen Systeme. Und dann wird es auch mit dem Asksin Eigenbauten schwer wenn man nur noch eine CCU hat oder?

Mhh naja dann schau ich mir mal diese CCU2 RPi Implementierung an. Werd ich mir mal ein RPi besorgen und dieses HM Modul und dann schau ich mal.

/Daniel

ZitatTrotz des blödsinnigen Namen "IP" ist es doch trotzdem 868 MHz und eine Art BidCos oder wie? Die eigentliche Umsetzung in IP macht doch dieser Access Point und die Wolke, sofern man das nutzt oder?

Irgendwie weiß ich nicht so richtig wie ich das am besten machen soll. Nur wegen einem Gerät jetzt eine extra CCU2 hinstellen und alle anderen "alten" HM Geräte sind direkt an FHEM angelernt ist nicht unbedingt sinnvoll oder?

/Daniel

.

Das ist nicht blödsinnig sondern tatsächlich IP über 868 MHz Funk (du weißt schon, OSI Layer und so)

Wenn du eine CCU hast, kannst du alles daran anlernen. FHEM behält seine Existenzberechtigung für alle nicht Homematic Sachen. Obwohl sich hier einiges getan hat. Mittlerweile kann die CCU Enocean, OSRAM, Sonos usw

Naja, Fhem macht schon noch sinn. Auch wenn die CCU2 einige weitere Protokolle und Addons unterstützt ist FHEM um einiges umfangreicher.
Ich habe zb einen pi mit CCU2 (YAHM) und fhem am laufen weil die CCU2 kein BT-Dongle zur Anwesenheit direkt nutzen kann oder auch die Darstellungs- und Bedienmöglichkeiten über FHEM besser sind

Zitat von: zap am 13 November 2017, 07:34:10
Das ist nicht blödsinnig sondern tatsächlich IP über 868 MHz Funk (du weißt schon, OSI Layer und so)

Mit riesen Overhead oder wie? hast du hier bitte die Protokoll Beschreibung zu Hand, ich finde nichts im Netz dazu außer Sales Kram der ja nun naja, wenig Aufschlussreich ist.

ich werd mir dann mal diese RPi Aufsteckadapter holen und eine CCU2 und dann schau ich mir das mal an. Ich hab ein bissel Angst, dass ich dann zwei Stellen habe an denen ich alles konfigurieren muss. Erst alles auf der CCU einrichten und dann auch noch in FHEM. (ich hab mir das CCU Modul noch nicht angesehen wie komplex das ist). Diese ganzen anderen Funktionen der CCU brauche ich nicht da ich eh in der Regel nie HM mit HM koppel sondern eher irgend etwas anderes mit HM was die CCU vermutlich nicht versteht.

Gruß
Daniel

Ja, an 2 Stellen zu konfigurieren bleibt nicht aus:
-CCU2: mind. Geräte anlernen und verknüpfen und konfigurieren (geht gerade mit YAHM / Raspberrymatic wesentlich schneller und einfacher als in FHEM mit registerschupsen)
-FHEM: Geräte anlegen und konfigurieren (geht fast von allein mit den default Tempates)

Es gibt noch andere Dinge, die nicht wirklich in die Richtung gehen, dass man in FHEM auf CUL_HM verzichten könnte. Die Anzahl der IODevs als Beispiel. Ich sehe diesen Weg nicht. HMIP ist für mich kein Grund. Zwave ist die bessere Alternative.

Zitat von: chris1284 am 13 November 2017, 08:03:58
Ja, an 2 Stellen zu konfigurieren bleibt nicht aus:
-CCU2: mind. Geräte anlernen und verknüpfen und konfigurieren (geht gerade mit YAHM / Raspberrymatic wesentlich schneller und einfacher als in FHEM mit registerschupsen)
-FHEM: Geräte anlegen und konfigurieren (geht fast von allein mit den default Tempates)

Vom Preis her ist CCU2 und RaspberryPi plus das Modul ja im Prinzip gleich. Du würdest also dennoch eher zum RPi tendieren? (Mein FHEM läuft auf einem anderen System, das bleibt auch so. Also auf den RPi soll kein FHEM rauf).

/Daniel

Zitat von: ext23 am 13 November 2017, 07:49:21
Mit riesen Overhead oder wie? hast du hier bitte die Protokoll Beschreibung zu Hand, ich finde nichts im Netz dazu außer Sales Kram der ja nun naja, wenig Aufschlussreich ist.

ich werd mir dann mal diese RPi Aufsteckadapter holen und eine CCU2 und dann schau ich mir das mal an. Ich hab ein bissel Angst, dass ich dann zwei Stellen habe an denen ich alles konfigurieren muss. Erst alles auf der CCU einrichten und dann auch noch in FHEM. (ich hab mir das CCU Modul noch nicht angesehen wie komplex das ist). Diese ganzen anderen Funktionen der CCU brauche ich nicht da ich eh in der Regel nie HM mit HM koppel sondern eher irgend etwas anderes mit HM was die CCU vermutlich nicht versteht.

Gruß
Daniel

Genau wie beim klassischen Bidcos gibt es keine Beschreibung.

Geht nur via reverse Engineering. Wobei HMIP vmtl (gegenüber Bidcos) einen drauf setzt und anstelle der XOR Verschleierung eine echte Verschlüsselung (imho AES) verwendet. IP V6 (Adressen) und Transportsecurity machen schon Sinn. Das mit dem Overhead ist relativ (IP wurde mal erfunden um im Falle eines Atomkriegs Signale über einen nassen Schnürsenkel von A nach B zu bekommen).

Ich würde mir das SDK (https://github.com/eq-3/occu) anschauen. Von dort aus gibt es imho verschiedene Ansätze. Entweder man lernt genug über das Protokoll um es (per fhem modul) nachzubilden - oder (besser?) - es lassen sich Einstiegspunkte via API (dokumentiert, undokumentiert) finden um ein fhem modul (auch in c mgl) "anzudocken". Ich meine: fhem muss ja nicht den IO direkt ansprechen. Genauso wenig den RPC der CCU. Dazwischen liegt ja eine (per GIT) verfügbare Bibliothek von eq3

vg
joerg

Man muss sich aber schon mal fragen ob es Sinn macht, so etwas zu entwickeln.

APIs gibt es ja schon lange und die sind auch dokumentiert: RPC  und Homematic Script (und JSON, wer es braucht). Diese APIs nutzt HMCCU und auch andere Plattformen wie OpenHab  oder IOBroker.

Wenn ich jetzt mal die 2 Varianten vergleiche:
1. FHEM mit CUL Stick und einem hypothetischen HMIP Software Modul
2. FHEM mit Funkmodul und OCCU sowie HMCCU

Das gibt sich kostenmäßig nichts. Der Vorteil von 2 ist aber das einfache Anlernen und Peeren von Geräten. Warum sollte man das Rad neu erfinden? Ok, mit CUL_HM ist das schon mal so passiert. Aber das muss sich mit HMIP ja nicht wiederholen.

definitiv. Für 2 ( FHEM mit Funkmodul und OCCU ) gibt es noch die Variante "andocken an die OCCU internen Funktionen". Dort könnte man (hypothetisch) sich so in die internen Funktionen der OCCU einklinken das es aus FHEM Sicht einen Software CUL ergibt ohne das man sich um die Internas des Protokolls kümmern müsste. Damit die Konfiguration (und co) komplett in fhem stattfindet.

Mein Verständnis ist dass man bei HMCCU die WebGui der virtuellen CCU benötigt. (Stimmt das?)

Zitat von: herrmannj am 13 November 2017, 11:55:48
...aus FHEM Sicht einen Software CUL ergibt ohne das man sich um die Internas des Protokolls kümmern müsste. Damit die Konfiguration (und co) komplett in fhem stattfindet.

Bin kein Experte ich diesen Dingen, aber es gab ja diverse Anfänger, die versucht haben, neue IP-Geräte mit HMUARTLGW einzubinden.
Was dort so als raw-Message zu sehen war, sah eigentlich nicht unbedingt so aus, als wäre das Signal noch verschlüsselt, es ähnelte eher "normalen" CUL-Ausgaben. Da das PI-PCB-Modul die AES-Verschlüsselung in der Hardware erledigt, bräuchte man evtl. nicht mal irgendwelche Basis-Services aus dem OCCU-Paket, um das an's Laufen zu bringen.

M.E. wäre eine direkte Einbindung der neuen Devices in FHEM ohne die Abhängigkeit von weiteren Diensten, die vorher erfolgreich gestartet werden müssen, vor allem für Anfänger ein echter Mehrwert.

ZitatBin kein Experte ich diesen Dingen, aber es gab ja diverse Anfänger, die versucht haben, neue IP-Geräte mit HMUARTLGW einzubinden.
Was dort so als raw-Message zu sehen war, sah eigentlich nicht unbedingt so aus, als wäre das Signal noch verschlüsselt, es ähnelte eher "normalen" CUL-Ausgaben. Da das PI-PCB-Modul die AES-Verschlüsselung in der Hardware erledigt, bräuchte man evtl. nicht mal irgendwelche Basis-Services aus dem OCCU-Paket, um das an's Laufen zu bringen.

Das wäre gut. Ich konnte jetzt (zugegeben auf die Schnelle) allerdings nichts dazu finden. Ich dachte eigentlich bis jetzt dass das genau nicht geht.

Mhhh also ich bin irgendwie raus. Ich werde mir einfach eine CCU2 und das andere Teil bestellen und dann probiere ich beides mal aus und dann werde ich die Vor- und Nachteile ergründen. Die kosten von knapp 70 Euro für die CCU2 sind ja nun überschaubar, auch wenn man 2 oder mehr braucht wegen der Reichweite. Ich persönlich habe eben nur etwas bedenken alles an zig Stellen zu konfigurieren. Dann kommt nachher nur die Hälfte an, dann fehlt der Batterie Status und und und, da habe ich etwas Bedenken. Und natürlich die Latenz wenn da noch zig Geräte und Dienste zwischen hängen um das zu konvertieren...

/Daniel

Zitat von: herrmannj am 13 November 2017, 12:37:09
Das wäre gut. Ich konnte jetzt (zugegeben auf die Schnelle) allerdings nichts dazu finden. Ich dachte eigentlich bis jetzt dass das genau nicht geht.

Ich habe auch etwas gesucht, aber auch nichts brauchbares gefunden, vielleicht bringe ich da auch was durcheinander :( .

Aber an sich müßte ja nur so ein PI-PCB nehmen, das Teil irgendwo seriell einbinden (notfalls USB, MapleCUN oä) und mal lauschen, was dort an der seriellen Schnittstelle so ausgespuckt wird, wenn man versucht, ein IP-Gerät zu pairen.

Aber das hat bestimmt ja schon mal jemand kompetentes versucht, also vergeßt es wieder...

Gruß, Beta-User

ich befürchte auch so einfach ist das nicht. Soweit ich weiß benötigen die HMIP Device ein Stück cloud um gepaired zu werden. Ich vermute das sich Zentrale und Device zu aller erst über einen AES Key einigen müssen.

Nee mach kein Scheiss, dann würde ich aber alt aussehen weil meine Systeme kein Weg ins Netz haben.

Der Key wird sicher aus der Seriennummer gebildet nehme ich mal an.

/Daniel

Zitat von: herrmannj am 13 November 2017, 13:37:29
ich befürchte auch so einfach ist das nicht. Soweit ich weiß benötigen die HMIP Device ein Stück cloud um gepaired zu werden. Ich vermute das sich Zentrale und Device zu aller erst über einen AES Key einigen müssen.

Hmmm, die Bedienungsanleitung des 6-fach-Wandtasters liest sich in diese Richtung (App oder CCU2)...

Hat mal jemand probiert, ob man die IP devices mit einer CCU2 pairen kann, die keine I-Net-Verbindung hat? Besser sollte man wohl sagen: und auch nie hatte...

Zitat von: ext23 am 13 November 2017, 13:40:53
Der Key wird sicher aus der Seriennummer gebildet nehme ich mal an.

Glaube ich nicht, das ist eher wie bei den "alten" ein einheitlicher Key für die gesamte Installation. Sonst müßte ja auch bei direkt gepeerten Geräten (so was soll ja auch mit HMIP gehen) jeweils pro gepeertem Device ein Key auf dem "Zieldevice" gespeichert werden. Dass hier plötzlich so viel potentere Hardware im Inneren werkelt, wäre m.E. eine Überraschung.

Aber wie gesagt: Ist definitiv über meinem Verständnis-Horizont...

Zitat von: herrmannj am 13 November 2017, 13:37:29
ich befürchte auch so einfach ist das nicht. Soweit ich weiß benötigen die HMIP Device ein Stück cloud um gepaired zu werden. Ich vermute das sich Zentrale und Device zu aller erst über einen AES Key einigen müssen.

nee, geht auch ohne Internet. Dann muss halt ein paar Daten vom beiliegenden Zettel abtippen, aber prinzipiell geht es ohne Internet (und damit Cloud).
Wobei ich sagen muss, dass das Pairing per Internet bei weitem einfacher (im Sinne von zuverlässiger) funktioniert, zumindest bei mir.

Zitat von: ext23 am 13 November 2017, 13:40:53
Nee mach kein Scheiss, dann würde ich aber alt aussehen weil meine Systeme kein Weg ins Netz haben.

Tschuldigung :D

Aber es ist gut wenn das das mal seriös von Dir untersucht wird :) Ich meine, sind von meiner Seite nur Vermutungen ...

Zitat von: herrmannj am 13 November 2017, 14:05:43
Tschuldigung :D

Aber es ist gut wenn das das mal seriös von Dir untersucht wird :) Ich meine, sind von meiner Seite nur Vermutungen ...

Edit: Überschnitten @kjmEjfu

Zitat von: Beta-User am 13 November 2017, 13:55:47
Glaube ich nicht, das ist eher wie bei den "alten" ein einheitlicher Key für die gesamte Installation. Sonst müßte ja auch bei direkt gepeerten Geräten (so was soll ja auch mit HMIP gehen) jeweils pro gepeertem Device ein Key auf dem "Zieldevice" gespeichert werden. Dass hier plötzlich so viel potentere Hardware im....

Oder so, macht Sinn ja. Die Seriennummer gibt man ja bei direkten Peering nicht bekannt.

Zitat von: kjmEjfu am 13 November 2017, 14:05:35
nee, geht auch ohne Internet. Dann muss halt ein paar Daten vom beiliegenden Zettel abtippen, aber prinzipiell geht es ohne Internet (und damit Cloud).
Wobei ich sagen muss, dass das Pairing per Internet bei weitem einfacher (im Sinne von zuverlässiger) funktioniert, zumindest bei mir.

Welche Daten zum Beispiel? Nur die Seriennummer? Oder was steckt da noch hinter dem barcode den man ja mit der App Abfotografiert noch drin?

hmmm, guter Ansatz. Wenn da der AES Key liegt hätte man schon mal eine Basis Richtung Klartext . Vielleicht ...

Zitat von: herrmannj am 13 November 2017, 11:55:48
Mein Verständnis ist dass man bei HMCCU die WebGui der virtuellen CCU benötigt. (Stimmt das?)

Um Gottes Willen, nein :-) Da müsste ich ja bei jeder Änderung des GUIs das Modul anpassen. Dafür bin ich viel zu faul ;-)

Ich benutze die RPC Schnittstelle sowie Homematic Script. Sonst nix. Also reine API Ebene.

Zitat von: zap am 13 November 2017, 14:29:46
Um Gottes Willen, nein :-) Da müsste ich ja bei jeder Änderung des GUIs das Modul anpassen. Dafür bin ich viel zu faul ;-)

Ich benutze die RPC Schnittstelle sowie Homematic Script. Sonst nix. Also reine API Ebene.

schon klar. Aber als Anwender, muss ich neue Device (HMIP) in der ccu anlernen oder geht das rein über fhem ?

Zitat von: ext23 am 13 November 2017, 14:07:52
Welche Daten zum Beispiel? Nur die Seriennummer? Oder was steckt da noch hinter dem barcode den man ja mit der App Abfotografiert noch drin?

Man ruft in der CCU2 "Anlernen" auf, wählt aus, ob man Wired, BidCos oder HMIP anlernen möchte und drückt das Knöpfchen am Gerät. Fertig. Falls man das nicht möchte, kann man die Nummer vom Aufkleber manuell eingeben.
Selbst die Anlernfunktion ist über das RPC API verfügbar. Habe sie nur nicht in HMCCU eingebaut, da es eben über die CCU viel einfacher geht.

So siehts aus (s. Anhang).

so ein SGTIN. Ist das EAN + Serial number ?

Sieht eher aus wie eine Kombi aus IPv6 Adresse + 4 stelligem Hex Code

Moin,

hab jetzt auch meine CCU2 zum spielen bekommen und mir zum Test ein HmIP-MOD-OC8 zu bestellt. Also da liegen zwei 2D Barcodes bei. Ein großer mit beiden Nummern, ein kleiner nur mit der SGTIN den man vermutlich auf das Gerät kleben soll:

Key: XXXXX-XXXXX-XXXXX-XXXXX-XXXXXX (0-9, A-Z)

SGTIN: xxxx-xxxx-xxxx-xxxx-xxxx-xxxx (Hex)


/Daniel

OK also Anlernen ohne Internet geht schon mal nicht. Steht ja auch da, nur für Internet. Da muss ich wohl die beiden Keys eingeben.

Also irgend etwas scheint er ja in der EQ3 DB abzufragen die aufm Server liegt wenn man das "einfache" Anlernen durchführen möchte...

/Daniel

Vermutung(!): AES key. Der wäre dann  individuell pro device. Also wenn.

Jupp wie ich oben schon geschrieben habe ja.

Irgend wann wird das auch alles einer verstehen ^^

Ist ja übelste langsam die CCU2, meine Herren ich hab doch nur 1 Gerät dran, so groß kann die DB doch gar nicht sein ^^

/Daniel

Kann ich so nicht bestätigen. Habe ca. 70 Geräte (HMIP/nonIP) in der CCU. Ja ist nicht die schnellste, aber ok (rein subjektiv). Wenn Du es schneller haben möchtest: Raspi mit OCCU und Funkstick.

Naja die ist schon gut am kotzen wenn ich auf der WebGUI was mache und parallel mit top schaue ;-)

Aber gut egal, sonst ist es ja ganz nett. Also da konfigurieren der Geräte ist natürlich um Weiten besser als das rumgefrickel in den Registern mit FHEM, das stimmt schon, kann man sich dran gewöhnen. Ich schau mir das jetzt mal an wie ich das ins FHEM bekomme und dann kann ich ja mal ein paar Gerät von meinem alten HM-LAN auf die CCU2 legen. Nur schade das ich den nicht nehmen kann zur Reichweitenverlängerung.

Für Reichweitenverlängerung benötigst du dann das LAN Gateway oder halt doch die PI Lösung mit externer Antenne

Naja den Adapter für die Pi habe ich ja mitbestellt, vorsorglich ;-) Ich wollte mir das später auch mal anschauen wie das so aussieht.

Die Leistung der eingebauten Antenne im Adapter ist geringer als die der CCU. Da ist eine externe Antenne empfehlenswert

Was lese ich da: Reichweitenverlängerung (für HM-IP, um das geht es in dieser Diskussion) mit dem HM-LAN-Gateway ... das soll möglich sein? Wäre mit neu. Ich hatte bisher die Info das geht nur mit der klapprigen CCU2.

Gruß, Klaus

Zitat von: zap am 16 November 2017, 18:11:41
Für Reichweitenverlängerung benötigst du dann das LAN Gateway oder halt doch die PI Lösung mit externer Antenne

LAN Gateway, nicht den HM LAN Adapter.... Also der ist gemeint:
https://www.elv.de/homematic-funk-lan-gateway.html

Das runde Ding was sich HM-LAN nennt funktioniert nicht.

/Daniel

Falsch.  Das LAN-Gateway kann nur das HM-Classic Protokoll, funktioniert nicht für HM-IP.  Steht auch ganz klar in der Produktbeschreibung bei ELV.

Genau das ist ja das Problem mit HM-IP in größeren Installationen: Reichweitenprobleme.  EQ3 versucht das dann mit Schaltsteckdosen als Repeater zu umgehen.

Gruß, Klaus

Aha, ich dachte das Teil ist dasselbe System wie die CCU2 mhhh und mit einer zweiten CCU2 kann man das auch nicht verlängern, die kost ja genauso viel...

Irgendwie ist das dich alles käse mit dem Hm-IP scheiss.

Ich meine wenn die ein Meshed Network aufbauen wollen hat so eine einzelne Steckdose doch wieder Probleme mit dem overload oder wie...

Naja ich seh da wirklich noch nicht ganz durch. Aber in der Anleitung zu dem Bausatz der CCU2 steht ja ein bissel was, und bei dem RPi Adapter auch. Also da ist es ein wenig erklärt wie das System der CCU2 aufgebaut ist. Das muss ich mir mal reinziehen.

/Daniel

Du kannst natürlich 2 CCUs einsetzen und beide mit HMCCU in FHEM einbinden. Nachteil: du hast dann 2 IODevs, wobei das für die einzelnen Gerätedevices keine Rolle spielt. Ist dann eine Lösung für mehr Reichweite, aber nicht als Ausfallsicherung einer CCU.

Naja das will man ja gerade nicht. Dann sind die Geräte ja auch Ortsgebunden was jetzt über FHEM nicht nötig ist. Da kann ich mit meiner Fernbedienung durchs ganze haus wandern und irgend ein HM-LAN wird es schon "regeln"...

geht mit der Homematic IP auch da einige Aktoren als Repeater fungieren können und für bidcos gibts auch repeater + das langateway.
Ausfallsicherheit haste bei CUL_HM auch nicht wenn du zb einen hmlan im Wsten und einem im Westen hast und einer davon ausfällt. Das Verteilen von iOs hast du so oder so wenn du große Strecken überwinden willst. also kein Vorteil für CUL_HM außer du nimmst 4 HMLAN (2 Ost, 2 West)

Also ich habe schon eine Ausfallsicherheit. Ich habe 3 und in der Regel empfangen mindestens 2 die Signale. Wenn das so bei der CCU2 auch geht das ich da 2 andere CCU2's anschließen kann und alle auch mit jeder reden können ohne ein erneutes Koppeln, dann ist gut ja. Klang so als wenn das nicht geht in dem Beitrag zuvor.

Ich habe 6 IODevs, wenn jemand im Keller ist 7. Und ich habe tatsächlich Ausfallsicherheit. Das lässt sich bei Nutzung von HMIP nicht abbilden.


Ich liebe mein ZWave mesh ;)

Naja, ich mag das mit der CCU2 auch nicht, aber irgendwie muss man sich wohl dran gewöhnen diesen Weg zu gehen. Ist ja auch nicht schlecht. Aber ich sehe bei der CCU2 null durch. Die Oberfläche ist irgendwie nichtssagend. Ich sehe auch nicht wenn ein Gerät aus ist und kein Signal mehr gesendet hat und welche Kanäle im Gerät oder in der CCU2 gemanaged werden. Beispiel der Wochentimer... Aber auch da wird viele gehen, man muss es nur wissen ;-) Aber das Teil ist echt sau langsam. Da frage ich mich wie langsam die CCU1 dann war... bei jedem klick muss ich gefühlte 5 Sekunden warten bis die Seite aufgebaut wird...

Ups, ich muss mich korrigieren, gerade kam eine Servicemeldung das ein Gerät nicht erreichbar ist, also es geht alles ^^

Wenn du die CCU in FHEM integrierst, sind solche Dinge wie Erreichbarkeit eines Gerätes per Reading erkennbar.

in einem HM-Thread mit ZWave mesh prahlen  ::)

ZitatIch sehe auch nicht wenn ein Gerät aus ist und kein Signal mehr gesendet hat

Was??? Augen auf! :D Erstens fängt die CCU2 an zu blinken (LED an der CCU) und du hast die Meldung "Gerätekommunikation gestört" in den dann gelben Servicemeldungen. Eigentlich nicht zu übersehene

Zitatund welche Kanäle im Gerät oder in der CCU2 gemanaged werden.

und auch das sieht man -> Einstellungen - Geräte -> "+" vor dme Gerät drücken und du siehst alle Channels. in der Tabelle gibt es dann  noch ein Auge, eine Hand und ein Notizbrett.
Auge -> Channel darfst du angucken
Hand -> Channel bedienbar
Notizbuch -> Channel wird protokilert

In Programme und Verknüpfungen -> Direktverknüpfungen kannst du zum einen nur kompatible Channels verknüpfen und dann die Verknüpfung konfigurieren (zb Fensterkontakt -> Thermostat)

Wenn du in Status und Bedienung geht werden dir pro Gerät eh nur die bedienbaren Channels  angezeigt.
Eigentlich ist die Oberfläche simpel und schon so gestaltet das man nur sinvolle Sachen machen kann

Also auch das Wochenprogramm wird komplett im Device geregelt ja? Sprich da rennt ne Uhr in jedem Device mit?

Eine Frage noch, wo sehe ich RSSI, Batteriestatus und ob AES an ist oder aus (beim alten HM). Unter FHEM sehe ich alles, aber nicht in dieser grausamen GUI der CCU2.

Hab das jetzt in FHEM eingebunden. klappt soweit, ist nur sehr sehr träge, also 5 Sekunden bis etwas aktualisiert wird, aber dann muss ich das auf den externen RPC umstellen wenn ich das richtig gelesen habe oder?

Wegen der LED, naja die sehe ich nicht, meine CCU2 liegt im Dreck ;-) Hier sind noch 300 andere LED's von den Switchen und und und, da fällt die eine nicht auf ^^ Zumal eine LED an der CCU2 immer blinkt ^^

/Daniel

Zitat von: ext23 am 18 November 2017, 09:24:09
Also auch das Wochenprogramm wird komplett im Device geregelt ja? Sprich da rennt ne Uhr in jedem Device mit?

Ja, eingestellt wird das über "Einstellungen -> Geräte" und den "Einstellungs-Button" z.B. bei einem Thermostaten. Wenn Du mehrere Geräte in einem Raum verknüpfen willst (Wand- und Heizkörperthermostat sowie Fenstersensoren) lege eine virtuelle Gerätegruppe an ("Einstellungen -> Gruppen"). Die CCU verknüpft dann wie von Zauberhand alles miteinander ;-)
Achtung! Gruppeneinstellungen haben Prio vor Wandthermostaten und die vor Heizkörperthermostaten. Soll heißen: Du änderst die Temperatur am Heizkörperthermostaten und der verknüpfte Wandthermostat überschreibt dir das wieder.

Zitat
Eine Frage noch, wo sehe ich RSSI, Batteriestatus und ob AES an ist oder aus (beim alten HM). Unter FHEM sehe ich alles, aber nicht in dieser grausamen GUI der CCU2.

RSSI: https://homematic-forum.de/forum/viewtopic.php?f=31&t=26624
AES: Einstellungen -> Geräte
Batterie: Als Servicemeldung, wenn eine leer ist

Zitat
Hab das jetzt in FHEM eingebunden. klappt soweit, ist nur sehr sehr träge, also 5 Sekunden bis etwas aktualisiert wird, aber dann muss ich das auf den externen RPC umstellen wenn ich das richtig gelesen habe oder?

Die Aktualisierung beim internen RPC-Server wird über das Attribut rpcInterval gesteuert. Das kannst Du auf 2 oder 3 setzen. Besser ist der externe RPC-Server. Die Aktualisierung ist quasi verzögerungsfrei.

Durchhalten!

Super danke, schau ich mir alles mal an.

Wegen der Zeiten, bei der Heizungsregelung ist das klar. Aber mit war neu das der HM mod8, also dieses billige IO Modul auch eine Uhr drin hat. Vielleicht auch nur das HM-IP Modell, bei dem HM Modul ist mir das gar nicht aufgefallen unter FHEM, dass man das da konfigurieren kann. Aber gut, umso besser.

Mit der Batterie und servicemeldung ist aber misst, was ist bei den Geräten wo ich die Spannung sehen "könnte".

Als Informatiker sagt mir FHEM mehr zu als die CCU... Da weiß ich was passiert und alles ohne bunten Schnulli ;-) Mit fehlt noch ein bissel debug logging auf der Funk seite. Aber da geht vielleicht was mit ssh, später....

Aber ich bin zufrieden. Läuft eigentlich alles. Gut diese Verknüpfungen und Programme brauche ich nicht, bei mir ist nichts direkt verknüpft. Aber kann man sich ja später mal anschauen. Ist mehr was wenn man ein reines HM Netz hat.

Wo ich die Wiki Einträge gelesen haben sah es alles so kompliziert aus aber es geht doch recht einfach. Ist nur fleissarbeit auf FHEM seite...

/Daniel

Eine Frage habe ich aber nochmal. Kann es sein das ein Mischbetrieb von HM-LAN und der CCU2 Probleme macht? Unter FHEM sehe ich das sich meine HM-LAN disconnecten sobald ich auf der CCU2 ein Schaltbefehl absetze. Das ist eindeutig reproduzierbar. Ich weiß nur nicht ob es am Funk liegt oder an der CCU2 Konfiguration in FHEM. Vielleicht ist das Problem weg wenn ich die ganze CCU2 nochmal aus FHEM schmeiße. Das weiß ich nicht.

Update: Passiert auch wenn der RPC Server gestoppt ist.

Und mit dem externen RPC ist es wirklich nahezu ohne Verzögerung!

/Daniel

ein alter hmlan mit fw ungleich 0.965 disconnected durch hmip.

Na da schau ich gleich mal nach. Ich hatte eigentlich erst ein FW Update gemacht.

Also ich muss sagen mit der CCU2 läuft das ganz gut. Ich habe jetzt eine Hand voll HM Geräte und ein HmIP Gerät angelernt die ich noch im Schrank rumliegen hatte und ja, läuft alles. Ich werde die bestehenden Geräte natürlich weiter am HM-LAN lassen aber ich lass die CCU2 mal mitlaufen.

Wenn dieser Repeaterbetrieb sauber läuft, könnte man ja drüber nachdenken alles auf die CCU2 zu legen.

Was passiert eigentlich mit HM Eigenbauten die keinem verfügbaren Gerät entsprechen? Bekommt man die auch irgendwie an die CCU2?

/Daniel

Zitat von: ext23 am 18 November 2017, 15:00:38
Was passiert eigentlich mit HM Eigenbauten die keinem verfügbaren Gerät entsprechen? Bekommt man die auch irgendwie an die CCU2?

Da muss dann entsprechend eine XML-Beschreibung erstellt werden.

Zitat von: papa am 18 November 2017, 15:18:57
Da muss dann entsprechend eine XML-Beschreibung erstellt werden.

OK, also wie bei HM mit FHEM auch. Naja wenn das geht ist ja eigentlich super.

Zitat von: chris1284 am 18 November 2017, 09:06:39
in einem HM-Thread mit ZWave mesh prahlen  ::)

Es ist ein HMIP Thread. Grundverschiedene Sachen im Bezug auf FHEM. Und hier darf man durchaus mal auf Hausautomatisierer freundlichere Technologien hinweisen. HM ist soweit ok aber HMIP... Meeeh. Als Nachfolger kaum geeignet.

Das hat aber einer das smile nicht deuten können ;)

OK also das Erkennen von offline Geräten scheint in der CCU2 nicht so sauber zu funktionieren. Oder ich habe etwas vergessen zu konfigurieren.

Ich hatte ein Gerät einen Tag aus, es wurde nicht gemeldet als gestört aber als ich es konfigurieren wollte kamen sofort 2 Meldungen:

Noch eine Frage, Thema RSSI:

devconfig auf der ccu2 sagt -38dBm, FHEM sagt:

DPT {n} BidCos-RF.KEQ0200XXX:0.RSSI_DEVICE = 1 [RE]
DPT {n} BidCos-RF.KEQ0200XXX:0.RSSI_PEER = 195 [RE]

Wie muss man das umrechnen?!?

/Daniel

Die Datenpunkte können Werte zwischen -128 und 127 annehmen. Vermutlich also 128 abziehen und wenn der ursprüngliche Wert >127 war mit -1 multiplizieren. Allerdings stimmt das nicht für dein Beispiel. Wobei die Werte ja nicht zeitgleich erhoben wurden, oder?

Naja ich hab schon beides zur gleichen Zeit abgefragt und selbst wenn, das Gerät liegt immer an der gleichen Stelle 2 Meter neben der CCU2. Also soooo groß sollten die Schwankungen nicht sein. Aber gut ich werd mal schauen ob ich zu einem Sinnvollen Ergebnis komme.

/Daniel

Mhh irgendwie haut da was nicht hin, der Wert unter FHEM bleibt immer gleich:

DPT {n} BidCos-RF.KEQ0200xxx:0.RSSI_DEVICE = 1 [RE]
DPT {n} BidCos-RF.KEQ0200xxx:0.RSSI_PEER = 195 [RE]

Welcher ist denn jetzt eigentlich der richtige? Device oder Peer? Besser gesagt was ist der Unterschied?

/Daniel

Doku zu den hm ip Geräten und Datenpunkten

http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HmIP_Device_Documentation.pdf

Allerdings steht da zu rssi auch nicht viel.

Update: die rssi Werte der Datenpunkte werden wohl nur beim Start der CCU aktualisiert. Peer Gibt den Wert einer direkten Verknüpfung an, device den Wert zur CCU Verbindung

Zitat von: zap am 22 November 2017, 12:56:36
Update: die rssi Werte der Datenpunkte werden wohl nur beim Start der CCU aktualisiert. Peer Gibt den Wert einer direkten Verknüpfung an, device den Wert zur CCU Verbindung

Mhh ok, das ist natürlich blöd ja.

Man kann die Werte über die RPC Schnittstelle abfragen. Das müsste ich mir mal anschauen. ...

Naja eigentlich braucht man das nicht. Schaut man sich einmal an und gut ist. Ich glaube nicht das irgend jemand ein Alarm triggert nur weil ein Gerät schlechten Empfang hat. Wenn die CCU2 das anzeigt, auch wenn etwas umständlich, dann reicht das ja eigentlich.

Übrigens auch nach einem CCU2 Neustart bleibt der RSSI Wert bei 1 stehen. Das ist ein HM-SCI-3-FM.

/Daniel

Woran kann das liegen, das die Readings nicht mehr aktualisiert werden?

HMCCU und HMCCURPC steht bei beiden running/OK. Das schalten funktioniert auch. Nur wenn ich an der Dose direkt bzw. über CCU2 schalte kommen die Werte nicht zurück...

/Daniel

Werden überhaupt keine Readings mehr aktualisiert?

Werden sie aktualisiert, wenn du für das Device get update ausführst?

Wurde die CCU zwischendurch neu gestartet?

Ich habe alles so gelassen, genau um das raus zu finden ;-)

- mit Update kommen die Werte
- Schalten von FHEM funktioniert auch
- Es betrifft alle Geräte
- Es betrifft alle Readings betreffend HMCCU
- Ich habe heute eine SD Karte nachgesteckt, und dabei muss man natürlich das LAN Kabel ziehen

Im log nur die Meldungen:
2017.11.24 20:33:45 2: HMCCURPC: Received no events from interface CB2010 for 600.768599033356 seconds
2017.11.24 20:33:45 2: HMCCURPC: Received no events from interface CB2001 for 600.768903017044 seconds

/Daniel

Ich nehme mal an, die CCU hat die Event-Registrierung vergessen. In HMCCURPC gibt es eine Option, die eine automatische Neuregistrierung bei der CCU auslöst. Allerdings fällt mir gerade das Attribut nicht ein. Könnte auch sein, dass das nicht immer funktionier. Habe da den ein oder anderen Bug gefunden, den ich gerade am korrigieren bin.
Aber versuchen kannst du es ja mal.

Kann ich mal schauen, aber mir geht es ja in erster Linie um das Problem an sich, das darf natürlich nicht passieren das bei einem Netzwerkausfall die Verbindung nicht mehr aufgebaut wird.

Ich schau mal was ich finde und ob es das Problem behebt, dann kennen wir ja die Ursache.

/Daniel

Im Attribut ccuflags reconnect anhaken

Genau, hat nicht gleich funktioniert aber nach einer Zeit ging es dann wieder.

/Daniel

Zitat von: zap am 25 November 2017, 13:23:55
Im Attribut ccuflags reconnect anhaken

dies habe ich hier gar nicht... ???

Sagt mal wie ist denn so die Erfahrung mit diesem CUxD? Ich lese ja im Netz einiges dazu. Nicht nur FS-20 sondern viele nutzen das auch mit den ESP's über WLAN etc.

Und hat schon mal jemand versucht die Diagramme der CCU2 woanders einzubinden? Ich stell mit mich FHEM zu blöde ein pro Monat ein Verbrauchsbalken in einer Jahresübersicht zu generieren. Jetzt wollte ich das mit PHP machen aber die Diagramme der CCU2 sind ja auch nicht sooooooo schlecht.

/Daniel

Zitat von: chris1284 am 26 November 2017, 08:49:16
dies habe ich hier gar nicht... ???

In HMCCURPC, nicht in HMCCU.

Da sollte es in ccuflags das reconnect geben. Allerdings funktioniert es nur in 90% aller Fälle, da ich da noch einen Bug drinhabe bzw eine seltene Konstellation nicht berücksichtige.

sehr geil:

https://www.heise.de/newsticker/meldung/Serverausfall-bei-Homematic-IP-3903589.html

/Daniel

Ja, ein gutes Beispiel, dass Smarthome Lösungen, die alleine auf Cloud Diensten basieren, großer Mist sind. Aber man kann HMIP ja auch nur mit der CCU nutzen.

Zitat von: zap am 28 November 2017, 21:31:54
Ja, ein gutes Beispiel, dass Smarthome Lösungen, die alleine auf Cloud Diensten basieren, großer Mist sind. Aber man kann HMIP ja auch nur mit der CCU nutzen.

Nicht nur SmartHome, das gilt für vieles das in der Wolke liegt, mittlerweile ganze Mobilfunknetze...

Zitat von: ext23 am 28 November 2017, 21:37:33
Nicht nur SmartHome, das gilt für vieles das in der Wolke liegt, mittlerweile ganze Mobilfunknetze...

Warum nur mag ich diesen Trend nicht.

Schnitzelbrain

Ich will Cloud Dienste nicht pauschal verteufeln. Es kommt eben darauf an, was ein Cloud Anbieter bereit ist, in seine Infrastruktur zu investieren. EQ3 fährt hier eben die Billigschiene (passt zu den Komponenten, billig gemacht und teuer verkauft).

Zitat von: schnitzelbrain am 28 November 2017, 22:16:50
Warum nur mag ich diesen Trend nicht.

Schnitzelbrain

Das Problem ist nur, frag mal deinen Bäcker, Friseur, Kurierfahrer oder Lehrer, wen auch immer. "Ohhhh Cloud, einfach, von überall erreichbar und und und..." Wer die Probleme nicht kennt und sich um Datenschutz nicht schert und selber nicht in der Lage ist die Vorteile der Cloud mit anderen Mitteln zu ermöglichen, naja der ist eben geil drauf. So wie ca. 95 % der Bevölkerung die nicht in der "echten" IT Arbeiten oder nichts mit Security am Hut haben....

In der Cloud wird geklaut ist für diesen Personenkreis auch nur ein Reim ohne Inhalt...

/Daniel

Zitat von: ext23 am 28 November 2017, 22:59:47
So wie ca. 95 % der Bevölkerung die nicht in der "echten" IT Arbeiten oder nichts mit Security am Hut haben....
In der Cloud wird geklaut ist für diesen Personenkreis auch nur ein Reim ohne Inhalt...

würde ich so nicht sagen... viel wissen nicht was Cloud bedeutet und nutzen sie daher nicht weil sie "angst" davor haben. So er meine Erfahrung.
Des Weiteren ist die Aussage "in der Cloud wird geklaut" auch ehr eine Stammtischparole. Es gibt solche und solche Clouddienste und meist ist das Problem ehr der User mit zb einfachsten Passwörtern, 1 Passwort für alles, 0 Akzeptanz für evtl 2 Faktor Authentifizierung, bedenkenlosem Umgang mit Daten (nicht nur was Daten in der Cloud angeht) und 0 Interesse sich kurz dazu zu informieren.
Auf der Anderen Seite kaufen große Unternehmen Massen an Cloudspeicher trotz eigener IT weil es einfach auch mal Vorteile bringt und auch sicher sein kann wenn man entsprechende Dienste vernünftig nutzt. Eine eigene Cloud zu basteln nur weil man OwnCloud auf nem pi(nas/whatever) installieren, nur einen Port am Router freigeben und eine App auf dem Handy installieren muss ist nicht gleich sicherere  ;) und gerade wenn man die Vorteile der Cloud nutzen will und keine Ahnung hat würde ich jedem zu einem bekannten Anbieter raten als selbst zu frickel

Ich denke auch, dass Cloud oft falsch interpretiert wird. Von 90% der Hersteller allerdings auch. Nach außen zumindest. Und deshalb ist die "Angst" bzw. Vorsicht auch durchaus berechtigt.

Naja Port auf und los geht es ist ja nun gerade das was man nicht machen soll ;-) bzw. was viele leider machen. Ohne IPSec geht da nichts...

2 Faktor Authentifizierung bringt auch nur was wenn es eine ist, und mTAN ist sicher keine, wird aber überall so beworben... Ist eben billiger als die HardToken (Oder meinetwegen auch SoftToken), ups schon wieder "billiger" mhhh.

Also bei unseren Kuden zählt nur eins warum Sie und die Cloud wollen, und das sind die Kosten... die natürlich letztendlich vom Endkunden bestimmt werden. Wirklich wollen tun die das aber sicher nicht. Und mit sinkendem Preis nörgeln die Kunden auch weniger wenn es hier und da mal Ausfälle gibt. Klappt bei der Telekom ja auch, das VoIP funktioniert vorne und hinten nicht, aber ist eben billig so das viele Kunden bereit sind die Komfortzone zu verlassen.

Und wie das mal endet wenn alle Formen in der MS Cloud Ihre Daten ablegen bin ich auch mal gespannt. Das öffnet der Betriebsspionage Tür und Tor. Solange alles funktioniert wie geplant ist ja gut... Die EU reguliert ja hier ordentlich. Aber wer will kontrollieren ob das Virtuelle Rechenzentrum wirklich auf EU Boden steht... Also ich sehe das alles schon sehr skeptisch. Nicht nur weil ich da irgendwo vorbelastet bin.

Hat ja auch Vorteile, dann macht man eben mal ein Tag nichts auf Arbeit wenn man nicht an seine Daten oder Emails kommt ^^.

/Daniel

Zitat von: zap am 25 November 2017, 13:23:55
Im Attribut ccuflags reconnect anhaken

Ich hab schon wieder das Problem, dass keine readings aktualisiert werden. Schalten geht aber... Also das attribut scheint nicht zu helfen.

Update: OK das HMCCU Gerät stand im Initialized mode, warum auch immer. Irgendwie scheint das noch nicht so ganz stabil zu laufen.

/Daniel

Gab es irgendwelche Meldungen im Logfile dazu?

Nein, das lief vermutlich seit dem letzten Restart nicht:

2017.12.17 21:26:17 1: HMCCU: Device CCU2_01. Initialized version 4.1.004
2017.12.17 21:26:18 1: HMCCU: Read 5 devices with 109 channels from CCU 192.168.0.46
2017.12.17 21:26:18 1: HMCCURPC: Device CCU2_01_rpc. Initialized version 0.98 beta

/Daniel

Hast du denn im IO Device das Attribut rpcserver auf on gesetzt?

Mhh natürlich nicht, also eigentlich doch, es war auf "onn" gesetzt, misst, kleiner Typo in der config.

Vielleicht sollte man das besser alles von hause aus als default setzen nach einem define? Man geht ja schon davon aus, dass alles nach einem FHEM restart auch weiterhin läuft wenn man es einmal per define eingerichtet hat, oder? Ich hab natürlich nur den Gutenberg gemacht und aus dem Wiki gezogen, ok selbst das scheint nicht so einfach zu sein wie ich feststellen muss, auch copy und paste möchte gelernt sein ^^.

/Daniel

Ich habe das gleiche Problem wie Daniel aus Post #196: Nach einiger Zeit werdrn keine Readings mehr aktualisiert.
Allerdings habe ich keine HMCCURPC wo ich das Attribut ccuflags reconnect setzen kann, weil ich den internen RPC_Server benutze, ich habe slso attr ccuflags intrpc gesetzt.
Weiss einer Abhilfe?