Hallo Leute,
gestern habe ich einen neuen Thermostat angelernt. Bei einem Blick in die "/opt/fhem/fhem.cfg" ist mir etwas für mich ungewöhnliches aufgefallen. Bei dem neuen Thermostat gibt es auf einmal zusätzlich das Attribut "IOgrp VCCU:HMUSB".
attr OG_WZ_Essbereich_Thermostat IODev HMUSB
attr OG_WZ_Essbereich_Thermostat IOgrp VCCU:HMUSB
Das gibt es bei den Thermostaten, die ich seit mittlerweile fast 3 Jahren in Betrieb habe, nicht. Dort ist immer lediglich das Attribut "IODev HMUSB" hinterlegt. Es schätze nun, dass ich die VCCU noch nie richtig in Betrieb hatte bzw. genutzt habe. Was mich nun wundert ist, dass plötzlich nach einigen Spielereien gestern mit den Peers im Wohnzimmer, 2 Thermostate agieren als Team, bei dem anderen Thermostat im Wohnzimmer, dass Attribut "IOgrp VCCU:HMUSB" ebenfalls auftaucht:
attr OG_WZ_Wohnbereich_Thermostat IODev HMUSB
attr OG_WZ_Wohnbereich_Thermostat IOgrp VCCU:HMUSB
Ich würde nun also bei allen Thermostaten das Attribut "IOgrp VCCU:HMUSB" nachziehen. Reicht das aus? Oder muss ich noch weitere Sachen ergänzen/anpassen?
Mein HMUSB- und VCCU-Config sieht wie folgt aus:
#HM-Gateway
define HMUSB HMLAN 127.0.0.1:1234
attr HMUSB hmId 123456
attr HMUSB hmLanQlen 1_min
attr HMUSB loadLevel 0:low,40:batchLevel,90:high,99:suspended
#HM-ActionDetector
define ActionDetector CUL_HM 000000
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector
#HM-VCCU
define VCCU CUL_HM 123456
attr VCCU IODev HMUSB
attr VCCU IOList HMUSB
attr VCCU expert 2_full
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update
Braucht ihr noch weitere Infos von mir?
Danke euch schonmal vorab und viele Grüße Hoppel
Hallo Leute,
ich nochmal. Ich denke meine Fragen haben sich geklärt. Ein Blick ins Wiki zeigt mir, dass das dort alles sehr gut beschrieben ist: https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
Anscheinend hat sich da eine ganze Menge seit der Einrichtung meiner VCCU vor 1 bis 2 Jahren geändert.
An der VCCU habe ich nun auch die "IOgrp VCCU" hinterlegt. Laut Wiki ist das ja auch erstmal das wichtigste. Ich bin mir sicher, dass das da damals noch nicht im Wiki stand. Kann mir sonst nicht erklären, warum das bei mir fehlte.
#HM-Gateway
define HMUSB HMLAN 127.0.0.1:1234
attr HMUSB hmId 123456
attr HMUSB hmLanQlen 1_min
attr HMUSB loadLevel 0:low,40:batchLevel,90:high,99:suspended
#HM-ActionDetector
define ActionDetector CUL_HM 000000
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector
#HM-VCCU
define VCCU CUL_HM 123456
attr VCCU IODev HMUSB
attr VCCU IOList HMUSB
attr VCCU IOgrp VCCU
attr VCCU expert 2_full
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update
Folgendes Attribut habe ich nun an all meinen Thermostaten hinterlegt:
attr OG_Buero_Thermostat IOgrp VCCU:HMUSB
Prefered Device ist also mein HMUSB. Momentan gibt es ja auch noch kein anderes IODev.
Habe ich sonst noch irgendwas übersehen?
Für Verbesserungsvorschläge bin ich jederzeit offen. ;)
Danke euch und Gruß Hoppel
Hi,
Du redest von zweierlei Dingen:
IOgrp muss bei allen vor dem Einrichten der VCCU schon existierenden Geräten manuell nachgepflegt werden. Das steht schon immer so im Wiki. Nach dem Einrichten der VCCU wird beim Pairing mit der VCCU dieses attr automatisch angelegt.
Das von Dir erwähnte attr IOgrp bei der VCCU ist dafür zuständig, dass die VCCU den IO zum Senden wirklich wechseln kann wenn ein IO ausfällt. Dieser Teil in der Beschreibung ist in der Tat erst seit einiger Zeit im Wiki.
Für die Steuerung des attr IOgrp bei den Geräten hat das keine Auswirkung.
Ich nehme an, Du hast die VCCU seiner Zeit einfach nicht komplett eingerichtet -> die attr IOgrp bei den existierenden HM Geräten nicht selbst gesetzt :D
Gruß Otto
Zitat von: Otto123 am 11 November 2018, 19:53:04
Du redest von zweierlei Dingen:
IOgrp muss bei allen vor dem Einrichten der VCCU schon existierenden Geräten manuell nachgepflegt werden. Das steht schon immer so im Wiki. Nach dem Einrichten der VCCU wird beim Pairing mit der VCCU dieses attr automatisch angelegt.
Echt? Dann habe ich es wahrscheinlich damals einfach nicht verstanden und es gekonnt überlesen. [emoji57] Vorhin war mir so, als ob ich das zum ersten Mal lese. Aber gut, nun habe ich IOgrp bei den älteren Thermostaten überall nachträglich ergänzt.
Zitat von: Otto123 am 11 November 2018, 19:53:04
Das von Dir erwähnte attr IOgrp bei der VCCU ist dafür zuständig, dass die VCCU den IO zum Senden wirklich wechseln kann wenn ein IO ausfällt. Dieser Teil in der Beschreibung ist in der Tat erst seit einiger Zeit im Wiki.
Für die Steuerung des attr IOgrp bei den Geräten hat das keine Auswirkung.
OK, sicherheitshalber müsste ich mir irgendwann mal ein weiteres IODev holen. Ein HM-CFG-USB-2 ist ja auch schon etwas veraltet. Aber bei meinen paar Thermostaten lohnt das noch nicht wirklich. [emoji6]
Zitat von: Otto123 am 11 November 2018, 19:53:04
Ich nehme an, Du hast die VCCU seiner Zeit einfach nicht komplett eingerichtet -> die attr IOgrp bei den existierenden HM Geräten nicht selbst gesetzt [emoji2]
Jupp, gehe ich auch von aus. Ich bin ja quasi noch FHEM Neuling. Wenn das erstmal läuft, muss man nicht unbedingt ständig damit herumspielen.
OK, dann denke ich, dass auch dieser Thread gelöst ist.
Danke und viele Grüße Hoppel
Nochmal eine Frage. Ich bin gerade am Überlegen, ob ich rein Spaßeshalber meinem HM-CFG-USB-2 einen Spielgefährten für die VCCU kaufe. Aber was wäre dann sinnvoll?
HM-CFG-USB-2 gibt es zwar nur noch bei ebay. Aber grundsätzlich stellt das für mich kein Problem dar. Es soll ja lediglich der Ausfallsicherheit dienen.
Oder macht es eher Sinn einen CUL oder irgendwas anderes zu bestellen.
Wenn ich nun einen CUL nehmen würde und diesen in die VCCU einbinden würde, könnte ich ihn dann gleichzeitig für Homematic-Komponenten und für Produkte anderer Hersteller verwenden, die auf der gleichen Frequenz funken? Oder ist der CUL dann exkl. für Homematic?
Was würdet ihr mir empfehlen?
Danke und viele Grüße Hoppel
Hi,
wenn dann einen IO exklusive für Homematic, alles andere ist Murks. Und wenn ich Dir raten darf: keinen CUL sondern einen richtigen Homematic IO.
https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale
Gruß Otto
Ok, danke für den Link. Dann bleibt meinen Anforderungen bzw. meinem Bedarf entsprechend eigentlich nur der HM-CFG-USB.
• CUL -> fällt heraus, da nicht empfehlenswert
• Funk LAN Gateway -> fällt heraus, da nicht empfehlenswert
• HM-MOD-RPI-PCB -> fällt heraus, da ich keinen RPI habe und auch keinen möchte
• HM-CFG-LAN -> könnte eine Alternative sein, gefällt mir aber nicht
Gibt es irgendwelche brauchbaren Alternativen, evtl. sowas wie einen Bausatz oder einen Adapter, um das HM-MOD-RPI-PCB per USB zu betrieben?
Dann hätte ich als zusätzliches IO noch was aktuelleres als den HM-USB.
EDIT: Habe gerade diesen Thread gefunden:
https://forum.fhem.de/index.php/topic,81387.0.html
Ich glaube, das ist nichts für mich. Das ist mir doch ein Bisschen zu viel Hardwaregefriggel.
Oder gibt es da etwas, was man einfach zusammensteckt und fertig?
Viele Grüße Hoppel
Zitat von: hoppel118 am 16 November 2018, 21:31:00
• HM-MOD-RPI-PCB -> fällt heraus, da ich keinen RPI habe und auch keinen möchte
Gibt es irgendwelche brauchbaren Alternativen, evtl. sowas wie einen Bausatz oder einen Adapter, um das HM-MOD-RPI-PCB per USB zu betrieben?
Dann hätte ich als zusätzliches IO noch was aktuelleres als den HM-USB.
EDIT: Habe gerade diesen Thread gefunden:
https://forum.fhem.de/index.php/topic,81387.0.html
Ich glaube, das ist nichts für mich. Das ist mir doch ein Bisschen zu viel Hardwaregefriggel.
Oder gibt es da etwas, was man einfach zusammensteckt und fertig?
Viele Grüße Hoppel
Wollte grad schreiben, dass der HMOD-PCB auch per USB, WLAN, ... "angeschlossen" werden kann...
...hast aber den Link selber gefunden... ;)
Wenn es zu viel HW-Gefrickel ist, gibt es bestimmt jemanden im Forum, der dir einen zusammen lötet...
Mit entsprechendem Gehäuse sieht es fast aus wie der HM-CFG-USB ;)
So einer liegt bei mir in der Grabbelkiste als Ersatz, falls mein HM-CFG-USB mal kaputt geht...
...bzw. ist Grabbelkiste falsch, ist grad an einen Bekannten verliehen... ;)
Gruß, Joachim
Wie funktioniert das per WLAN? Brauche ich dafür dann noch einen RPI oder was brauche dafür für Teile?
Welchen Vorteil siehst du beim RPI-PCB im Vergleich zum HM-USB?
Danke und Gruß Hoppel
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
ZitatFunk LAN Gateway -> fällt heraus, da nicht empfehlenswert
Wie kommst Du darauf?
Zitat von: hoppel118 am 16 November 2018, 22:39:17
Wie funktioniert das per WLAN? Brauche ich dafür dann noch einen RPI oder was brauche dafür für Teile?
Welchen Vorteil siehst du beim RPI-PCB im Vergleich zum HM-USB?
Danke und Gruß Hoppel
Nein keinen PI.
Max. ein PI ZeroW und dann per ser2net oder so...
Besser/billiger ESP8266 als "Seriell-WLAN-Bridge", also serielles "Kabel" durch die Luft ;)
Anschluss genauso wie den USB-Adapter und dann halt z.B. espLink (glaube ich heißt die Software) drauf laden...
...aber auch da gibt's bestimmt was im Forum in fertig ;)
Vorteil(e): Preis und v.a. (noch) "normal" zu kaufen...
Gruß, Joachim
Ok, in dem Link wird quasi alles beschrieben. Aber wie funktioniert das per WLAN?
Gibt's da wirklich nichts fertiges für HM-UART-USB oder HM-UART-WLAN? :)
@MadMax-FHEM Habe gerade mal nach diesem ESP8266 gegoogelt. Für mich ist das einfach irgendein Bauteil/Chip. [emoji12] Ich bastel ja ganz gerne. Aber alles was über Zusammenstecken hinausgeht, ist eigentlich nichts für mich. Das ist für mich wie beim Kompilieren und Programmieren:
• Kompilieren: ok
• programmieren: nein danke... [emoji6]
Gibt es außer der Verfügbarkeit noch irgendein anderes Problem mit dem HM-USB?
Zitat von: hoppel118 am 16 November 2018, 23:04:19
@MadMax-FHEM Habe gerade mal nach diesem ESP8266 gegoogelt. Für mich ist das einfach irgendein Bauteil/Chip. [emoji12] Ich bastel ja ganz gerne. Aber alles was über Zusammenstecken hinausgeht, ist eigentlich nichts für mich. Das ist für mich wie beim Kompilieren und Programmieren:
• Kompilieren: ok
• programmieren: nein danke... [emoji6]
Gibt es außer der Verfügbarkeit noch irgendein anderes Problem mit dem HM-USB?
Kompilieren wirst du evtl./vermutlich müssen, da es drauf ankommt welchen ESP8266 du hast/haben wirst ;)
Programmieren eigentlich nicht.
Die Bridge (bzw. mehrere Varianten) gibt es fertig.
Runter laden -> compilieren -> auf den ESP spielen
Es sind "nur" 4 Drähte zu löten (leider nicht stecken): Tx, Rx, Vcc, Gnd
Genauso wie beim USB-Adapter beschrieben...
Aber ich würde mal im "fhem Marketplace" eine Anfrage nach einem Fertigen oder Lötauftrag platzieren.
EDIT: Problem mit dem HM-CFG-USB? Nein. Läuft prima. Aber als "Ersatz" habe ich mir halt mal einen USB-Adapter selbst gebastelt im Schrank... Einen "überteuerten" (evtl. sogar gebrauchten) HM-CFG-USB wollte ich da einfach nicht haben...
Gruß, Joachim
Ok, ich lass mir das mal durch den Kopf gehen. Jetzt kenne ich auf jeden Fall schonmal meine Möglichkeiten.
Danke euch beiden!
Zitat von: Otto123 am 16 November 2018, 20:52:05
wenn dann einen IO exklusive für Homematic, alles andere ist Murks. Und wenn ich Dir raten darf: keinen CUL sondern einen richtigen Homematic IO.
Man kann an einem CUL auch einen "richtigen" HM-IO nutzen, indem man einen HM-MOD-UART drauf steckt:
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Ist evtl. das beste aus beiden Welten?
Für Wlan:
Wemos D1 mini und das Modul kaufen, das HM RPI Modul gibt es bei ebay auch fertig gelötet. Dazu bräuchte man ein Netzteil 5 Volt und 4 Strippen zum Stecken.
Der Wemos wird mit esp-link geflashed.
Fertig ohne Löten und Programmieren und kompilieren - nur stecken und flashen.
Gruß Otto
Zitat von: Otto123 am 17 November 2018, 10:29:25
Für Wlan:
Wemos D1 mini und das Modul kaufen, das HM RPI Modul gibt es bei ebay auch fertig gelötet. Dazu bräuchte man ein Netzteil 5 Volt und 4 Strippen zum Stecken.
Der Wemos wird mit esp-link geflashed.
Fertig ohne Löten und Programmieren und kompilieren - nur stecken und flashen.
Gruß Otto
Oh, gut zu wissen! :)
Gruß, Joachim