[erledigt] ccu2 wiki - mach ich alles richtig?

Begonnen von the ratman, 21 März 2018, 08:31:51

Vorheriges Thema - Nächstes Thema

the ratman

hiho,

bin nur etwas verwirrt. ich hab mir eben eine ccu2 an fhem geklebt. nun hab ich eine hmlan (warscheinlich bald am sterben) und eben die ccu2 am laufen.
das ganze soll über ne vccu laufen.
ich hab versucht, nach https://wiki.fhem.de/wiki/HMCCU zu arbeiten, stoße da aber über einträge die ich so nicht finde.
wiki veraltet oder ich zu blöd?

gut, der stand der dinge:
vccu meint, dass ccu2 ok ist
ccu2 selber meint: running und OK
im hm webinterface hab ich bis jetzt lediglich die neuste firmware installiert und dann nach wiki die fw konfiguriert
in fhem hab ich eig. noch gar nix bei der ccu2 gemacht und bei der vccu nur die ccu2 als weiteres device in die iolist eingetragen

wars das nu oder muß ich noch was einstellen bei ccu2 oder vccu?
bin ich schon drin? *g*

sorry für die sicher dämlichen fragen, aber der "verwirrfaktor" aus n wiki ist wieder mal recht hoch ...
→do↑p!dnʇs↓shit←

marvin78

Du hast sicher ein falsches Verständnis darüber, wie die CCU2 in FHEM eingebunden wird. Das passiert nicht direkt als IODev, wie beim HMLAN. Du kannst mit FHEM aber die CCU2 steuern. Die Einstellungen zu HM Geräten machst du dann in der CCU2, du kannst diese aber auch über FHEM steuern und auslesen. Die Devices haben dann andere Readings und werden nicht mehr direkt über FHEM gesteuert.

Die CCU2 ersetzt also nicht den HMLAN, es ist eine völlig andere Art der Einbindung von Homematic in FHEM.

Und das Wiki ist eigentlich sehr klar. Wie immer, musst du vermutlich nur deine Gedanken ordnen ;)

the ratman

#2
bspl für meine verwirrung - rpc server konfiguration:
lt. wiki geht da einiges einzustellen. ich hab jetzt aber nur on/off und das auch noch 2 mal - einmal bei set und einmal als attr.
oder:
soll ich nun in denn attr interfaces einstellen und wenn ja welche. oder reicht es, dass in den internales schon interfaces angegeben sind? oder steht in den internals was geht und ich muß es über die attr dann auswählen?
oder:
mit get update sollte ich ja meine devices von fhem an die ccu2 senden können. da kommt bei mir nur n popup mit 0 client devices successfully updated. Update for 0 client devices failed

kannst du mir dann bitte auch sagen, wie ich hmlan und ccu2 zu einer gemeinsamen arbeit bewegen kann, oder geht das nun doch nicht?
ccu2 zurück senden oder hmlan aus dem netz reißen? vorher hatte ich ja einen hmusb als "backup". aber der läuft unter meiner virtuellen box extrem unzuverlässig. drum erst die idee mit der ccu2.
ich meine im forum mehrfach (frag nicht nach links bitte, du weißt ja, was da an irrsinnigen mengen an beiträgen rumschwirren) gelesen zu haben, dass das ja alles angeblich kein problem sein soll.

oder ganz simpel: wie würdest du vorgehen, wenn du ne vccu mit hmlan und ne ccu2 in fhem hättest und möglichst einfach alles miteinander reden lassen wollen würdest?
es geht eben rein nur darum, dass eines der devices steuert und das andere nur als ein quasi backup dient.

ZitatWie immer, musst du vermutlich nur deine Gedanken ordnen ;)
da gibts zu zeit wenig zu ordnen - mein hirn rennt grad schon wieder auf notfall-ein-bahnhof-ist-ein-spanisches-dorf-modus.
→do↑p!dnʇs↓shit←

Beta-User

Versuch, die Dinge zu ordnen:

Wie im Wiki zu Homematic (dort: Voraussetzungen) dargestellt, gibt es zwei prinzipiell _ganz verschiedene, sich gegenseitig bei dem selben Gerät wechselseitig faktisch ausschließende_ Wege, HM-BidCoS-Geräte einzubinden:
_Entweder_ als HM_CUL-Geräte über IO-Devices CUL bzw. HMUARTLGW
_oder_ mit der CCU2 als IO (dann: HMCCU).

Du kannst jetzt entweder deine "alten" IO-Geräte der CCU2 unterordnen und dann darüber steuern, oder du schickst das Ding zurück und nimmst ein anderes IO, das BidCoS spricht (z.B. ein Pi-PCB mit einem ESP, MapleCUN ..., also halt einem Gerät, das eine serielle Schnittstelle@3.3V im Netz bereitstellt), wenn die direkte Einbindung via USB das Problem ist.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

marvin78

Zitat von: the ratman am 21 März 2018, 08:59:37

da gibts zu zeit wenig zu ordnen - mein hirn rennt grad schon wieder auf notfall-ein-bahnhof-ist-ein-spanisches-dorf-modus.

Deshalb erstmal ordnen. Meinen Beitrag lesen und dann den von Beta-User. Kurz: Das war du möchtest geht nicht. Es gibt ein entweder oder.

the ratman

gut, soweit kapiert. danke mal für die dau-fähigen ausführungen *g*.
irgendwie hab ich also wohl einfach wieder mal die falschen beiträge im forum gelesen oder diese total falsch verstanden.
wenn ich also nochmal kurz nerven dürfte ...

zum grundlegenden:
intelligent wärs wohl, wenn ich eher auf die ccu2 setze - allein schon wegen dem neuen hmip-zeugs und wohl auch, weil man auch viel ohne ein fhem machen könnte, so man wollte. soweit richtig?
das würde also bedeuten - wie von euch erwähnt: ich muß meine jetzigen geräte quasi umziehen zur ccu2, verschrotte mein hmlan und vergiss die vccu.
hmlan scheint weiterhin als eine art repeater für die ccu2 zu funzen. richtig? wenn ja, ist das fhem egal oder wieder was zu bedenken?

bliebe also nur noch die frage:
wie mach ich das am intelligentesten und sichersten?
und wie ich euch 2 kenn, kennt ihr sicher auch schon die stolpersteine, über dies mich dabei werfen könnte, oder?
→do↑p!dnʇs↓shit←

marvin78

WENN du das machen möchtest, verwendest du in der CCU2 die selbe HMID, wie in FHEM und du musst nicht neu pairen. Wie genau das von statten geht (Anlage der Geräte in der CCU2), weiß ich nicht, ich kenne die CCU2 nicht.

WENN ich ggf. irgendwann man auf HMIP setzen würde (noch sehe ich keinerlei Vorteil und im Gegensatz zu anderen finde ich die Geräte auch nicht "hübscher - bei mir sind neue Geräte meist ZWAVE Modelle), dann würde ich nur diese über eine CCU2 bzw. eine entsprechende Raspi Lösung steuern und den Rest bei FHEM belassen. Dann spare ich mir Redundanz und habe weiterhin meine 6 IODevs in FHEM. Das ist nämlich so mit einer CCU2 nicht möglich. Es gibt einen Maximalwert für IODevs (3?). Im Grunde ist das aber eine Entscheidung, die jeder für sich selbst treffen muss. Es gibt hier im Forum Leute, die versuchen daraus eine Art Glaubenskrieg zu machen, am Ende kommt es aber auf die individuelle Umgebung und Vorlieben an.

the ratman

Zitatin der CCU2 die selbe HMID
wow! hab ich ausnahmsweise auf anhieb richtig gedacht *g*
Zitatnoch sehe ich keinerlei Vorteil und im Gegensatz zu anderen finde ich die Geräte auch nicht "hübscher - bei mir sind neue Geräte meist ZWAVE Modelle
geb ich dir recht. ich will auch nur a bissi zukunftssicherer sein, wenn ich das ding nun schon hab. die extra dünnen magnetkontakte habens mir angetan und die durchgangskontrolle mit dem personenzähler. der rest lässt mch auch kalt.
zwave is halt schöner, ja, aber ich brauch kein geblinke an den wänden, will lieber alles verstecken. ich hab nur 3 sensoren gehabt, davon sind 2 hardwaremäßig nach wenigen monaten abgeraucht und einer ist nie gegangen. ein ersatzsensor ist dann in seinen einzelteilen von der küchenwand gefallen (gehäuse hat sich aufgelöst), da hats mir gereicht mit zwave. nix für meine nerven!

mein problem is halt auch: mein hmlan lässt sich nicht mehr updaten. ich krieg das ding nicht auf die neueste version geflashed und ich hab lustigste abbrüche seit 2 wochen. bevor ich da nun auch wieder die große ratekiste auspack, mach ich lieber gleich nen strich unter mein jetziges konzept.
hoff ich halt mal, dass mir beta-user noch ein oder 2 schupse in die richtige richtung gibt, ich scheiter ja schon bei meinen ersten umzugsversuchen.
ein get ccu2 devicelist create ^4K12V.* t=all f=schalter_4K12V_%n defattr save room=homematic
bringt auch nur "Read 1 devices with 51 channels from CCU     Created 0 client devices"
das sollte mir ja meinen schalter mit seinen 4 knöpfchen umziehen denk ich mal - aber warscheinlich hab ich da auch wieder mal alles falsch verstanden.
→do↑p!dnʇs↓shit←

Beta-User

Zitat von: the ratman am 21 März 2018, 11:38:31
hoff ich halt mal, dass mir beta-user noch ein oder 2 schupse in die richtige richtung gibt, ich scheiter ja schon bei meinen ersten umzugsversuchen.
Sorry, ich habe auch keine CCU2 (und werde mir definitiv auch keine zulegen, auf meinem Speiseplan bleibt für den Fall der Fälle zwave stehen ;) . Und zur Glaubensfrage: ich halte es für besser, möglichst direkten Zugriff auf Geräte zu haben, daher vermeide ich selbst jeden derartigen "Umweg", wenn das halbwegs sinnvoll geht...).

Das größte Problem sehe ich darin, dass die ganzen Namenskonventionen anders sind. Wenn du viele Auswertungen (notify, DOIF, perl-scripte hast), mit denen du rumhantierst:

Mach dir erst mal eine Übersicht, welche Auswirkungen die geänderte Namensgebung hätte (auch auf set-Befehel usw.). Entscheide erst dann, wenn du das weißt, ob es besser ist, alles auf einen Rutsch zu machen (gleiche ID für die CCU2) oder ob es einfacher ist, das Stück für Stück zu tun (zwei HmID's, dann jedes Device einzeln umziehen und die Logik anpassen). Ggf. geht es auch, die "Datenpunkte" der CCU2 umzubenennen, das würde manches vereinfachen.

Mehr fällt mir dazu aber nicht ein...

Wenn du dazu Aufzeichnungen machst, ist das evtl. hilfreich für potentielle Nachahmer, es scheint ja durchaus einige zu geben, die auch diesen Weg zur CCU2 gehen wollen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

Zitatmein problem is halt auch: mein hmlan lässt sich nicht mehr updaten. ich krieg das ding nicht auf die neueste version geflashed und ich hab lustigste abbrüche seit 2 wochen.
wenn der hmlan hmIP messages hört, hast du wohl keine chance. versuch es mal im wald, oder schirme ihn gegen funk ab.

ohne hmlan müsstest du ja auch alle hm devices auf die ccu umziehen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

the ratman

ZitatWenn du dazu Aufzeichnungen machst, ist das evtl. hilfreich für potentielle Nachahmer, es scheint ja durchaus einige zu geben, die auch diesen Weg zur CCU2 gehen wollen.
sobald ich mal weiß, wies geht, gerne *g*. btw: "wollen" ist n starker ausdruck. ich sitz halt derzeit auf den erwähnten problemen fest: hmusb ist unzuverlässig bei meiner konstellation und hmlan will nicht mehr so recht. hmlan update geht nicht und ich kann z.b. meine einfachen 12v-schalter nur mehr empfangen, keine befehle senden. der rest rennt zwar, aber wie lange noch?

ich hoff halt jetzt mal, dass mein hmlan lange genug überlebt, bis hier ein wissender was zu sagt. der gedanke, alle meine doifs und rg's umzubauen macht mich auch nicht wirklich glücklich ... würde wohl bedeuten, dass ich 95% neu/umschreiben darf.
mal schaun, was nu früher passiert *g* ...

@frank:
ich hab die ccu2 erst seit heute und kein einziges ip-gerät bis jetzt.
das updateproblem hab ich schon länger am hmlan. jetzt fängts mir halt auch noch an, div. geräte nicht mehr korrekt anquasseln zu können, die seit 1 jahr problemlos gelaufen sind.
Zitatohne hmlan müsstest du ja auch alle hm devices auf die ccu umziehen.
stellt sich eben die frage: wie mach ich das am besten und einfachsten.
→do↑p!dnʇs↓shit←

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

the ratman

nachbarn gibts meines wissens nach nicht. wie könnt ich das rauskriegen?
→do↑p!dnʇs↓shit←

Beta-User

Warum nimmst du nicht zu dem hmlan noch ein weiteres Interface? Notfalls ein CUL, bis die PI-PCB's wieder verfügbar sind...

Und da war bei den hmlans nicht auch noch so ein Thema mit Kondensatoren? Kann sein, dass der recht einfach zu reparieren wäre (würde ich aber auch erst versuchen, wenn ich entweder wüßte, dass es sicher klappt oder eine Backuplösung schon am laufen hätte).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

Zitat von: the ratman am 21 März 2018, 12:29:39
nachbarn gibts meines wissens nach nicht. wie könnt ich das rauskriegen?
indem du es mit dem update zb noch mal im wald probierst.   ;)

in der vccu müssten wohl auch neue unknown readings existieren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

the ratman

wird mir eh nix anderes übrig bleiben ...

ich denk, wenn sich nicht kurzfristig ein einfacher umzug ergibt, ich werd die ccu2 zurück geben und n weiteres hmlan nehmen. mir is es egal, ob meine komponenten direkt rennen oder sonst wie, solang sie rennen.
raspi hab ich keinen mehr für fhem, lauft bei mir mittlwerweile alles über meinen win-server mit ner vm. die macht aber eben wieder probleme mit meinem hmusb. und jetzt hab ich auch noch franks laus mit den nachbarn im kopf. verhalten würd ja fast passen, wenn ich so manchen beitrag im forum drüber anlese.
wobei das immer noch nicht erklärt, warum ich auch übern hmlan-configurator gar nix mehr seh ausser ausgegraute buttons und der homematic configurator zwar meine geräte findet, aber meint, das er sie wegen eines fehlers nicht konfigurieren kann. in fhem sind die dinger aber erreich- und schaltbar (bis auf eines).

@frank
dann is es wohl so - ich sehe gerade 3 neue readings. unknown_292986 received 2018-03-20 16:09:15
unknown_523829 received 2018-03-21 12:54:48
unknown_5CC6F2 received 2018-03-21 07:59:44
dachte immer, die kommen von meinen versuchen, meinen 12v-schalter wieder ins leben zurück zu bekommen.
was nu? dann nutzt mir n neuer hmlan warscheinlich auch nix
→do↑p!dnʇs↓shit←

Beta-User

Zitat von: the ratman am 21 März 2018, 12:58:18
raspi hab ich keinen mehr für fhem, lauft bei mir mittlwerweile alles über meinen win-server mit ner vm.
Für den Fall, dass das auf meine Hinweise auf das Pi-PCB bezogen war: Das Ding braucht nicht unbedingt einen PI ;) , meins hängt z.B. auch an einem USB-Seriell-Wandler, da auch mein ThinClient keine GPIO's hat. Das ganze geht auch via Netz, wie bereits geschrieben:
Zitat von: Beta-User am 21 März 2018, 09:38:27
[...] nimmst ein anderes IO, das BidCoS spricht (z.B. ein Pi-PCB mit einem ESP, MapleCUN ..., also halt einem Gerät, das eine serielle Schnittstelle@3.3V im Netz bereitstellt), wenn die direkte Einbindung via USB das Problem ist.
Sähe z.B. dann so aus:
https://forum.fhem.de/index.php/topic,85764.msg781603.html#msg781603, gibt aber auch einen Thread zu...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

das hmIP problem haben nur alte hmlan mit fw < 0.965. es gibt jetzt ja nur noch neue hmlan, lan-gate-way, zu kaufen.

ein unknown reading ist sicherlich die neue ccu. du kannst ja mal die ccu ausschalten, bei der vccu set clear unknown machen, und warten, ob wieder neue unknown readings kommen. die müssten dann ja vom nachbarn kommen, falls bei dir nicht doch noch ein undefiniertes device rumfunkt.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

the ratman

@betauser
ich weiß net. diese bastellösungen machen mich wenig glücklich, besser: nervös. bin eh schon schwach auf dem gebiet, da muß ich nicht auch noch zusätzliche probleme ins haus bringen. muß imner denken: gegen euch hab ich schon mit den einfacheren sachen schwierigkeiten. und ich geh jetzt mal frech davon aus, das solche lösungen weniger klicki-bunti-kompatibel sind, als der eh schon komplexe rest..
und "USB-Seriell-Wandler" ... geht schon ein "normaler" usb-stick nur schleppend über die vm, da hätte ich damit sicher viel spaß.
ich hätte mir mal fast das hier angebotene wlan-interface kaufen wollen. leider hat der erbauer mit mir nicht per pn reden wollen ...

@frank
2018-03-20 16:09:15 --> da hat ich noch keine ccu2, bzw sie noch nicht ausgepackt.
meine eig. devices sind erkannt, bzw. stromlos. da kanns also auch ned herkommen, denk ich mal.
und das nicht-erscheinen, bzw fehler-melden der hm-tools würds wohl maximal auch nur teilweise erklären.
→do↑p!dnʇs↓shit←

Beta-User

Zitat von: the ratman am 21 März 2018, 13:57:59
ich weiß net. diese bastellösungen machen mich wenig glücklich, besser: nervös. bin eh schon schwach auf dem gebiet, da muß ich nicht auch noch zusätzliche probleme ins haus bringen.
Ich bin auch nur "Verlegenheitslöter" und hatte die Hälfte meiner FHEM-Zeit auch - nennen wir es Vorbehalte dagegen -, "sowas" einzusetzen, geschweige denn selber zu machen. Und schön aussehen ist ... anders... Und an eine virtuelle Maschine würde ich das Teil auch nicht per USB hängen.

Es ging "nur" darum klarzustellen, dass es nicht zwangsläufig ein HMLAN sein _muss_.

Alles andere findest du auf dem Marktplatz, die meisten Teile (z.B. MapleCUN) gibt es auch fertig gelötet, in der Regel mit bereits geflashter Firmware, und sind dann einfach zu konfigurieren - die Lötstelle für das Pi-Modul ist dort zumindest auch gut zu erkennen.

Aber klar: Deine Entscheidung :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

the ratman

das is ja das dumme: eig. is es ja nicht meine entscheidung. die wird mir von meinem wissens/können-stand abgenommen. immerhin kenn ich den stand dank euch mittlerweile recht gut. leider *g*.

ich meinte auch weniger das löten. wennst mir nicht grad smd bausteine mit meiner china-schrott lötstation löten lasst, hab ich das halbwegs im griff, wenns auch kein hobby von mir ist. mein problem ist immer das "hintenan". dort, wos dann ans fehlersuchen bei der "software" geht. oder eben auch ans verstehen, was so ein linux/perl/... pro eigentlich meint, wenn er anfangt: "das ist ganz leicht, du mußt nur ...". sobald ich das les, krieg ich schon nen gehetzten blick. mir fehlt eindeutig der google-übersetzer für "pro <-> noob".
fazit:
ich versuche alles zu vermeiden, was die "das ist ganz leicht"-leute so basteln/programmieren. um diverse teile in der richtung kommt man halt nicht rum, wenn man auch nur geringste ansprüche an seine hausautomatisation (fhem), oder z.b. auch nen guten player (foobar2000) hat. drum quäl ich mich dann durch, für mich zu 75%, unverständliches zeug.
und nicht in den falschen hals kriegen bitte! ich beschwer mich keineswegs über die qualität von fhem, oder der hilfe in diesem forum. eher das gegenteil is der fall. ich bin schwer begeistert, was hier so an gehirnschmalz rum rennt. es ist meistens nur immer viel zu viel mögliches und zu sehr ins detail, wennst grad nen "notfall" hast. da hast als noob hintenan mehr fragen als vorher ...

langer rede, wenig sinn:
ich wart jetzt einfach mal nur auf das wunder, dass hier jemand schreibt, der das alles mit nem umzug auf ne ccu2 schon gelöst hat und mir n paar tipps geben kann, oder ich probier mich mit nem neuen hmlan irgendwann nächste woche. das ist definitiv die noob-sicherste version, denk ich mal.
→do↑p!dnʇs↓shit←

Beta-User

Lustig, als "ein linux/perl/... pro" fühle ich mich definitiv nicht (auch wenn ich mittlerweile auch manches über perl lösen kann) und das mit "Mist, Bahnhof, wo ist hier der schnelle Ausgang?!?" kenne ich nur zu gut ::) .

Aber zur Einbindung eines Pi-Moduls, das mit genau 4 Kabeln an einem ESP oder MapleCUN mit einem Sketch hängt, der dessen serielle Schnittstelle ins Netz bringt: Es verhält sich bei der Einbindung in FHEM genau wie was? ...
Genau: Ein original LAN-Gateway ;D .

Ergo würde ich behaupten, dass das (neben der Bestellung des Originals) die einfachste Variante ist, die du wählen kannst. Jedenfalls deutlich einfacher, als die ganze Logik umzubauen ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

the ratman

#22
jo, soweit sind ma uns einig. meine hoffnung, dass hier wer aufschlägt, der mit 3 zeilen den umzug auf ccu2 erklärt - tjo, groß ist sie nicht  ...
in anbetracht der 2 oben erwähnten ip-komponenten, die ich so geil fände, geb ich dem wunder aber übers wochenende ne chance.ich tausche lieber gleich, bevor mir das meine baldige reise versaut ...

du hast es versaut "an einem ESP oder MapleCUN mit einem Sketch hängt, der dessen serielle Schnittstelle ins Netz bring" ... ich hab angst! dabei hab ich die worte noch nicht mal nachgeschlagen *g*.
das geile: ich krieg ja sogar 15,- zurück, wenn ich die ccu2 gegen ein hmlan tausch ... in dem fall is mir also wurst.

mittlerweile frag ich mich tatsächlich eher, warum mein hmlan so spinnt, warum ich ihn nichtmal auf 95 updaten kann. ich wills schwören, ich hatte den upgedatet. nachdems hier aber keine geister gibt, bin ich ratlos ...
und natürlich frag ich mich dank frank: was mach ich gegen böse nachbarn, sollts die geben? ich hätte noch n bissi brandbeschleuniger, hmmm ....
→do↑p!dnʇs↓shit←

zap

Mit drei Zeilen kann dir das keiner erklären. Zunächst müsstest Du Dich zumindest etwas in das Thema CCU einlesen. Dann könntest Du Deine Geräte an der CCU anlernen und sinnvoll benennen. Und schließlich müsstest Du HMCCU nach Wiki und Commandref einrichten.
Die Erklärungen zu den Attributen rpcserver und rpcinterface sind m.E. schon im Wiki ausreichend. Im Zweifel gibt es noch die Commandref. Alles vorkauen wird dir niemand. Dafür habe ich schließlich relativ viel Zeit in die Doku investiert. Wenn aber etwas nicht so funktioniert wie beschrieben, helfe ich natürlich gerne.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

the ratman

ist zwar schon egal - morgen kommt hermes und holts ccu2 wieder ab.
aber "alles vorkauen", is etwas übertrieben. ging ja eigentlich um den umzug von hmlan auf ccu2. das scheint auf die art wohl noch keiner gemacht zu haben, da dies scheints unverhältnismäßig viel arbeit bedeutet.
der rest hier ist wohl eher zwischen smalltalk und grundsatzdiskussion einzuordnen, wobei ich für meinen teil wieder mal einiges an infos mitnehmen konnte.

ich lass den fred aber mal offen, da ja einige genau an so nem umzug interesse zu haben scheinen. vielleicht kann man sich ja doch mal helfen.
→do↑p!dnʇs↓shit←

Beta-User

Zitat von: the ratman am 21 März 2018, 15:52:18
du hast es versaut "an einem ESP oder MapleCUN mit einem Sketch hängt, der dessen serielle Schnittstelle ins Netz bring" ... ich hab angst!
Wie gesagt, wenn man's nicht selber bauen will, gibt's sowas hin und wieder auf fertig, siehe z.B. hier: https://forum.fhem.de/index.php/topic,86277.0.html. Dto. für einen MapleCUN (wobei man da die Platine wirklich noch selber auflöten müßte).

Mit Strom versorgen, einbinden wie ein "normales" Lan-Gateway, that's it ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

the ratman

o.k. ganz vergessen.

alle probleme beseitigt - ich hatte ne echt dämliche kaskade an problemen/fehlern. läuft wieder alles.
von meiner seite her alles erledigt, thx!
→do↑p!dnʇs↓shit←