Hallo,
ich möchte euch auf diesem Weg mitteilen wie es mir gelungen ist die HomematicIP Komponenten direkt mit FHEM auszulesen.
Ihr benötigt lediglich den Python wrapper für die HomematicIP REST API (von coreGreenberet [github]) ich hoffe das ich das hier teilen darf.
Nach der Einrichtung der HomematicIP-REST-API habe ich die Daten mittels Python ausgelesen und den Rückgabewert passend aufbereitet.
"devicevalue.py"
# coding=utf-8
import os.path
from operator import attrgetter
import config
import homematicip
from homematicip.home import Home
home = Home()
home.init(config.ACCESS_POINT)
home.set_auth_token(config.AUTH_TOKEN)
home.get_current_state()
sortedDevices = sorted(home.devices, key=attrgetter('deviceType', 'label'))
def show_shutter(device):
print (u"{}_{}:\nBatterie-{}_{}:".format(d.label,d.windowState, d.label, d.lowBat))
def show_heatingthermostat(device):
print (u"{}_{}:\nBatterie-{}_{}:".format(d.label,(d.valvePosition*100), d.label, d.lowBat ))
def show_wallmountedthermostatpro(device):
print (u"Temperatur-{}_{}:\nLuftfeuchte-{}_{}:\nBatterie-{}_{}:".format(d.label,d.actualTemperature,d.label,d.humidity, d.label, d.lowBat))
for d in sortedDevices:
if isinstance(d, homematicip.device.ShutterContact):
show_shutter(d)
elif isinstance(d, homematicip.device.HeatingThermostat):
show_heatingthermostat(d)
elif isinstance(d, homematicip.device.WallMountedThermostatPro) or isinstance(d, homematicip.device.TemperatureHumiditySensorDisplay):
show_wallmountedthermostatpro(d)
In der FHEM.cfg habe ich dann einen Dummy angelegt für das Device und ein Notify um den Rückgabewert in einzelne Readings aufzuteilen.
FHEM.cfg
define HomematicIP dummy
define HomematicIPAnDummy at +*00:00:05 { my $reading =homematicip();;}
define n_HomematicIP notify HomematicIP {readingSplit($NAME,$EVENT)}
Um das Python-Script auszuführen und die Reading aufzuteilen habe ich der 99_myUtils.pm noch Subroutinen erstellt.
99_myUtils.pm
#---------------------------------------
# Homematic-Funktion
#---------------------------------------
sub homematicip(){
my $returnCode = qx(python3 /home/pi/homematicip-rest-api/devicevalues.py);
fhem("setReading HomematicIP HomematicIP $returnCode");
}
#---------------------------------------
# Reading Split-Funktion @_;
#---------------------------------------
sub readingSplit($$) {
my ($name,$event) = @_;
my @paare = split(/:/,$event);
foreach my $p (@paare){
my ($r,$v) = split(/_/,$p);
fhem("setreading $name $r $v");
}}
Ich hoffe das euch das hilft bis jetzt lese ich die Werte nur man kann aber auch Werte schreiben mithilfe der HomematicIP-REST-API
Hi,
ich hatte mich etwas gewundert, warum das plötzlich so einfach gehen sollte, die HM-IP Teile direkt anzusprechen. Nach ein klein wenig Suche habe ich jetzt den Eindruck, dass das nur mit dem "Access Point" geht, was auch bedeutet, dass es immer über die Cloud geht. ...oder?
In dem Fall wäre mir die CCU2 lieber, da das meines Wissens nach auch lokal funktioniert.
Gruß,
Thorsten
Ja richtig also die Daten holt man sich von der Cloud und nicht direkt von den einzelnen Geräten.
Ich überlege gerade, ob es Sinn macht, HMCCU so zu erweitern, dass es neben einer CCU2 auch den Accesspoint unterstützt.
Das Cloud-Thema halte ich eher für einen Nachteil, vor allem wenn man sich an das EQ-3 Cloud-Disaster Ende letzten Jahres erinnert. Da ging gar nichts mehr. Da habe ich lieber eine CCU2 (egal ob jetzt als "Box" oder auf einem Raspi). Das funktioniert auch ohne Internet.
Ich notiere mir das mal für "zukünftige Erweiterungen". Ich glaube, die meisten HMIP Nutzer haben eine CCU2.
Danke für deine Umsetzung, die API konnte ich soweit anbinden deine Notifys und Dummys habe ich auch übernommen, sowie die Subrutine in der 99_myUtils.
Ich habe nur das Problem, dass bei mir Teile der Namen mit im Reading stehen.
So sehen meine Werte auf der API nach deiner devicevalues.py aus:
Heizkörperthermostat Kinderzimmmer _34.0:
Batterie-Heizkörperthermostat Kinderzimmmer _False:
Temperatur-Wanthermostat Wohnzimmer _22.3:
Luftfeucht-Wanthermostat Wohnzimmer _48:
usw.
Wie muss ich deine Subrutine anpassen, damit das zerlegen in einzelne Reading passend funktioniert?
Zitat von: zap am 22 Januar 2018, 18:26:32
Ich überlege gerade, ob es Sinn macht, HMCCU so zu erweitern, dass es neben einer CCU2 auch den Accesspoint unterstützt.
Das Cloud-Thema halte ich eher für einen Nachteil, vor allem wenn man sich an das EQ-3 Cloud-Disaster Ende letzten Jahres erinnert. Da ging gar nichts mehr. Da habe ich lieber eine CCU2 (egal ob jetzt als "Box" oder auf einem Raspi). Das funktioniert auch ohne Internet.
Ich notiere mir das mal für "zukünftige Erweiterungen". ....
Gibt es da Neuigkeiten?
Nein. Bin momentan mit der HMCCU Version 4.4 beschäftigt. Das ist sehr aufwändig.
Okay, klar, das kann ich verstehen - gerne würde ich helfen, aber sorry, das ist leider weit über meinen Fähigkeiten.
Aber wenn es irgendwann mit dem Accesspoint klappen sollte, ich wäre bestimmt nicht der einzige Begeisterte.
Gruß und vielen Dank
Hallo,
kann mir bitte jemand erklären, wie ich die "Homematic IP Rest API" installieren muss?
Ich bin noch Anfänger und komme mit der Installation nicht klar.
In der Anleitung steht
Just run pip3 install -U homematicip in the command line to get the package.
Das sagt mir aber leider nix. Wenn ich mich per SSH einlogge erhalte ich auf:
pi@raspberrypi:~ $ pip3 install -U homematicip
-bash: pip3: Kommando nicht gefunden.
pi@raspberrypi:~ $ install -U homematicip
install: Ungültige Option -- U
,,install --help" liefert weitere Informationen.
Linux und ich sind nicht wirklich Freunde ;)
Hat jemand einen Tipp für mich?
Vielen Dank...
[Edit]: Ich habe ein Homematic IP System mit einem Access Point und würde die Geräte gern in FHEM sehen (steuern wäre nicht ganz so wichtig). Ich habe keine CCU und möchte auch nicht unbedingt ein RaspberryMatic benutzen da FHEM an sich schon alles tut, was ich will.
Wäre nur schön die Daten von den Homematic IP Geräten auch in FHEM zu haben. Oder gibt es da mittlerweile einen besseren Weg?
Zitat
-bash: pip3: Kommando nicht gefunden.
naja da hast du wohl eben pip3 nicht installiert...
Und das hat nix mit Linux zu tun ;)
Wenn du auf Windows Word verwenden willst, muss es auch installiert sein ;)
https://www.raspberrypi.org/documentation/linux/software/python.md
Wenn du ein Raspbian OS LITE hast, musst du pip erst installieren...
Gruß, Joachim
@ersthelfer: Brauchst du den AP wirklich als AP?
Zum Hintergrund der Frage:
Du scheinst Einsteiger zu sein. Diese Lösung hier würde ich als experimentell bezeichnen, was sich nicht gut mit dem "Einsteiger" verträgt, zumal dir wohl auch diverse Linux-Basics fehlen, und auch die Implementierung in "Senderichtung" hier nur angedeutet ist, also auch entsprechende Einarbeitung verlangt.
Afaik kann man den AP auch "umflashen" und als IO für eine (virtuelle) CCU (für die Module HMCCU.*) verwenden. Eventuell ist das der einfachere Weg... (gibt eine aktuelle Diskussion dazu, ein großer Discounter hatte da jüngst was dazu im Angebot, bitte da bei Interesse weitersuchen)
Kommt aber ggf. auch darauf an, was du schon über den AP am laufen hast. Wenn es wenig ist, müßten eventuell die Devices abgelernt werden usw.. Viel mehr kann ich zu dem ganzen aber nicht beitragen, wollte nur den Hinweis loswerden.
(EDIT: Das mit dem Umflashen bezieht sich insbesondere auf den Hinweis von Jamo in diesem Beitrag: https://forum.fhem.de/index.php/topic,105016.msg1095684.html#msg1095684. Vermutlich braucht man nur die CCU-Software (z.B. virtualisiert auf einem Pi), um diesen Anlernvorgang ggf. anstoßen zu können, also keine weitere Hardware. Ist aber nur eine Vermutung...).
Zitat von: Beta-User am 05 November 2020, 09:48:11
@ersthelfer: Brauchst du den AP wirklich als AP? .....
...(... ein großer Discounter hatte da jüngst was dazu im Angebot...)
Genau das versuche ich ja gerade herauszufinden.
Ich habe beim erwähnten Discounter ;) ein Set mit AP, Thermostat und Türkontakt gekauft und möchte die jetzt in meinem FHEM benutzen.
Bei mir läuft FHEM auf einem PI. Meine meisten Geräte sprechen MQTT und auch Alexa spielt mit meinem FHEM.
Des Weiteren habe ich einem MAX-Cube über den Thermostate und Türkontakte laufen und alles ist gut.
In der letzten Zeit sterben mir aber immer mehr MAX Komponenten weg und EQ3 hat diese Linie ja eingestellt. Deshalb gibt es da wohl auf lange Sicht Beschaffungsprobleme.
Also dachte ich mir, gut CUL-Stick in den PI und auf Homematic IP umstellen. Wenn ich das jedoch richtig verstanden habe, kann der CUL-Stick kein HM I, oder?
Deshalb bin ich jetzt auf der Suche wie ich den AP mit meinem FHEM verbinden kann. Wenn ich den AP umflashen kann, wäre das vermutlich genau das was ich brauche.
Ich möchte jetzt nicht zusätzlich noch eine CCU laufen haben, da meine komplette Steuerung ja wunderschön von dem PI und FHEM erledigt wird.
Ich hoffe diese Erklärung beschreit mein Problem ordentlich....
Danke für Eure Antworten...
Na ja, meine persönliche Meinung zu eQ-3 ist zwischenzeitlich: Hände weg von allem, was irgendwie propretär ist, es gibt auf längere Sicht anderswo tendenziell mind. gleichwertige Alternativen... Die sind (nur & noch) nicht so weit hier im Forum verbreitet.
Back to topic:
Dein "Problem" war naheliegend, daher habe ich das auch entsprechend formuliert ;D .
In dem Edit in meinem vorherigen Post findest du einen Link mit einer Anleitung, wie man das Ding unter die Kontroller einer CCU bringen kann und meine Vermutung, was dazu (nicht) erforderlich ist. Also teste es aus, berichte und bring' es ins Wiki...
Ich werde mich derweil mit anderem beschäftigen, ich habe da z.B. grade ein paar interessante ZigBee-Devices aus China im Zulauf, z.B. zwei (1 und 2-Kanal-) UP-Aktoren, die man scheinbar in europ. UP-Dosen hinter bestehende Schalter OHNE Nullleiter unterbringen kann (Stück <20 Euro). Da kannst du bei eQ-3 lange warten, bis die sowas in HM-IP anbieten... (Aber bei solchen Experimenten weiß man nie, ob es läuft und wenn ja, wie lange bzw. wie lange es dauert, bis der betr. Aktor in den Interface-Dienst integriert ist).
Zitat von: Beta-User am 05 November 2020, 12:00:49
...wie man das Ding unter die Kontroller einer CCU bringen kann...
So wie ich das gelesen habe brauche ich wieder eine CCU dafür, oder?
Und die wollte ich ja jetzt nicht zusätzlich :-[
...eigentlich hätte ich ja wetten können, dass die Frage kommt....
piVCCU? Oder eine andere virtualisierte Lösung?
(Es gibt mehrere Varianten dafür und sowas findet man u.a. alles auch - zumindest in Stichworten, daher der Hinweis, dass an der Stelle Aktionsbedarf besteht, falls es funktioniert (...!) - im Wiki, aber das liest ja heutzutage keiner mehr)...
Zitat von: Beta-User am 05 November 2020, 12:00:49
Ich werde mich derweil mit anderem beschäftigen, ich habe da z.B. grade ein paar interessante ZigBee-Devices aus China im Zulauf, z.B. zwei (1 und 2-Kanal-) UP-Aktoren, die man scheinbar in europ. UP-Dosen hinter bestehende Schalter OHNE Nullleiter unterbringen kann (Stück <20 Euro). Da kannst du bei eQ-3 lange warten, bis die sowas in HM-IP anbieten... (Aber bei solchen Experimenten weiß man nie, ob es läuft und wenn ja, wie lange bzw. wie lange es dauert, bis der betr. Aktor in den Interface-Dienst integriert ist).
:)
Welche wären das!?
Da hätte ich evtl. auch Interesse :)
Zitat von: Beta-User am 05 November 2020, 12:00:49
Da kannst du bei eQ-3 lange warten, bis die sowas in HM-IP anbieten...
Ich glaube nicht, dass da (jemals) sowas kommt.
Gab es ja nicht mal bei Homematic "Classic", drum hatte ich ja "damals" auch noch IT drin...
Gruß, Joachim
Zitat von: MadMax-FHEM am 05 November 2020, 12:45:09
Welche wären das!?
Da hätte ich evtl. auch Interesse :)
...auch darauf hätte ich wetten können, dass das jemand interessiert...
Typenbezeichnung ist u.A. QS-Zigbee-S05-L, findet man z.B. in der Bucht mit den Schlagworten "Tuya Zigbee 3.0 Wifi Smart Switch Drahtloses Fernschaltermodul Relais EU 220V" - Schaltleistung ist aber für Leuchtmittel (bis 100W) ausgelegt (ggf. sind das Mehrfachangebote mit unterschiedlichen Modellen!).
Überhaupt gibt es mit "Tuya Zigbee 3.0" seit kurzem noch mehr interessante Treffer, z.B. einen "Scene controller 4 gang" - ein 4-fach-Batterie-Taster (je einfach+Doppelklick und Lang (release?)); der könnte von den Außenmaßen her ggf. zu/in Jung CD passen...
Ist aber alles erst unterwegs, werde berichten ;) .
Zitat von: Beta-User am 05 November 2020, 13:02:09
...auch darauf hätte ich wetten können, dass das jemand interessiert...
Ich wollte dich nur nicht "enttäuschen" ;)
Zitat von: Beta-User am 05 November 2020, 13:02:09
Typenbezeichnung ist u.A. QS-Zigbee-S05-L, findet man z.B. in der Bucht mit den Schlagworten "Tuya Zigbee 3.0 Wifi Smart Switch Drahtloses Fernschaltermodul Relais EU 220V" - Schaltleistung ist aber für Leuchtmittel (bis 100W) ausgelegt (ggf. sind das Mehrfachangebote mit unterschiedlichen Modellen!).
Überhaupt gibt es mit "Tuya Zigbee 3.0" seit kurzem noch mehr interessante Treffer, z.B. einen "Scene controller 4 gang" - ein 4-fach-Batterie-Taster (je einfach+Doppelklick und Lang (release?)); der könnte von den Außenmaßen her ggf. zu/in Jung CD passen...
Ist aber alles erst unterwegs, werde berichten ;) .
Werde ich mir mal anschauen...
...und bin gespannt! :)
Gruß, Joachim
Zitat von: Beta-User am 05 November 2020, 09:48:11
Afaik kann man den AP auch "umflashen" und als IO für eine (virtuelle) CCU (für die Module HMCCU.*) verwenden.
Das ist so nicht ganz richtig. Man kann das Ding zwar umflashen und als Reichweitenverlängerung nutzen, aber nur zusätzlich zu dem RPI-RF-MOD als HMIP-Hauptfunkmodul.
Der billigste Weg zu einer virtuellen CCU fü HMIP ist HM-MOD-RPI-PCB, aufgesteckt auf einem Raspi, und piVCCU, damit der Raspi auch für andere Zwecke genutzt werden kann.
Hmm, ok, Danke für die Erhellung, Praxis schlägt Theorie...
Hatte ja geschrieben, dass ich nur vermute, dass das klappen könnte, und Alexander/deimos (?) war mir so im Ohr, dass piVCCU (z.B. auf x86-Systemen) auch ohne Pi-Modul lauffähig wäre, sofern nur irgendein (ggf. im LAN erreichbares) IO verfügbar ist, das die Timings beherrscht (alternativ: per USB mit einem speziellen Adapter).
Eventuell sollte man mal ihn zu Rate ziehen, evtl. kann man da was tweaken. Grundsätzlich scheint das Teil im "Slave"-Modus aber nicht als Mesh-Repeater zu fungieren, sondern als eigenständiges IO - so deute ich jedenfalls das, was Jamo aaO. berichtet hat - und damit müßte es eigentlich prinzipiell als einzige Funkschnittstelle auch tauglich sein.
Soweit meine Theorien, viel Freude noch an HM-IP...
Zitat von: Horti am 05 November 2020, 14:11:04
Das ist so nicht ganz richtig. Man kann das Ding zwar umflashen und als Reichweitenverlängerung nutzen, aber nur zusätzlich zu dem RPI-RF-MOD als HMIP-Hauptfunkmodul.
das "umflashen" habe ich in der anleitung eher als "fw-update" des accesspoint verstanden.
bist du dir sicher, dass die "ccu" dann wirklich noch den hmuart benötigt?
laut anleitung soll der vorteil des accesspoint als router ja sein, dass der dutycycle des "normalen" funkmoduls nicht belastet wird. dann kann es ja eigentlich kein herkömmliches "routing" über funk sein, wie zb bei den steckdosen.
somit hätte ich den verdacht, dass es auch nur mit accesspoint funktionieren könnte.
es wäre ja auch seltsam, dass wenn das "normale" funkmodul ausfällt, dadurch dann auch alle accesspoint router nutzlos wären.
ich denke, ich muss mir mal einen accesspoint besorgen.
Zitat von: Beta-User am 05 November 2020, 14:42:03
Hatte ja geschrieben, dass ich nur vermute, dass das klappen könnte, und Alexander/deimos (?) war mir so im Ohr, dass piVCCU (z.B. auf x86-Systemen) auch ohne Pi-Modul lauffähig wäre, sofern nur irgendein (ggf. im LAN erreichbares) IO verfügbar ist, das die Timings beherrscht (alternativ: per USB mit einem speziellen Adapter).
Es geht nichts über gesundes Halbwissen ;) Ja, der Alexander hat 2 (besser gesagt 3) Platinen entwickelt, um die Funkmodule RPI-RF-MOD oder HM-MOD-RPI-PCB in der CCU über USB oder WLAN einzubinden. Insofern nicht "irgendein" IO-Device und nicht "irgendwie" erreichbar.
Zitat von: Beta-User am 05 November 2020, 14:42:03
Eventuell sollte man mal ihn zu Rate ziehen, evtl. kann man da was tweaken. Grundsätzlich scheint das Teil im "Slave"-Modus aber nicht als Mesh-Repeater zu fungieren, sondern als eigenständiges IO - so deute ich jedenfalls das, was Jamo aaO. berichtet hat - und damit müßte es eigentlich prinzipiell als einzige Funkschnittstelle auch tauglich sein.
Für HMIP gelten strenge Vorgaben bzgl. Signallaufzeit, deswegen scheidet WLAN von vornherein aus. Deswegen kann man da auch nicht "was tweaken", auch "sollte man mal ihn zu Rate ziehen" kann man sich sparen, er hat das oft genug erläutert.
Zitat von: frank am 05 November 2020, 15:06:46
das "umflashen" habe ich in der anleitung eher als "fw-update" des accesspoint verstanden.
Laüft ja aufs Gleiche hinaus, es muss eine andere/neue Firmware drauf.
Zitat von: frank am 05 November 2020, 15:06:46
bist du dir sicher, dass die "ccu" dann wirklich noch den hmuart benötigt?
Ich bin mir sehr sicher, dass man noch das RPI-RF-MOD braucht als Hauptfunkmodul, hmuart reicht dafür nicht. Ob es technisch notwendig ist, oder eq-3 den Absatz von RPI-RF-MOD steigern möchte, vermag ich nicht zu beurteilen.
Zitat von: frank am 05 November 2020, 15:06:46
laut anleitung soll der vorteil des accesspoint als router ja sein, dass der dutycycle des "normalen" funkmoduls nicht belastet wird. dann kann es ja eigentlich kein herkömmliches "routing" über funk sein, wie zb bei den steckdosen.
somit hätte ich den verdacht, dass es auch nur mit accesspoint funktionieren könnte.
es wäre ja auch seltsam, dass wenn das "normale" funkmodul ausfällt, dadurch dann auch alle accesspoint router nutzlos wären.
ich denke, ich muss mir mal einen accesspoint besorgen.
s. oben, sinnvoll oder nicht, aber RPI-RF-MOD ist eine zwingende Voraussetzung. Angeblich, weil irgendeine HW-Komponente davon mit für die Verschlüsselung genutzt wird, wie auch schon beim HMIPW. Dass es nicht mit HM-MOD-RPI-PCB geht, kann ich aus eigener Erfahrung bestätigen, ich habe hier nämlich schon einen HAP liegen.
Ok, dein Wissen geht über mein Halbwissen raus, auch wenn das mit den Latenzen mAn. erst ab der Funkschnittstelle gilt (sofern das IO kein "dummes" IO ist, wie das bei einem Pi-PCB+ESP8266 der Fall ist)...
Mind. ein Grund mehr, sich mit Alternativen zu den proprietäten Lösungen von eQ-3 zu beschäftigen... :P Ich mache dann mal weiter mit ZWave und ZigBee 8) . Auch jweils nicht ganz einfach, aber günstiger, teils flexibler und zumindest besser standardisiert bei größerer Auswahl (auch, was Anbieter angeht). Bin dann mal raus.
Zitat von: Beta-User am 05 November 2020, 16:04:45
Ok, dein Wissen geht über mein Halbwissen raus, auch wenn das mit den Latenzen mAn. erst ab der Funkschnittstelle gilt (sofern das IO kein "dummes" IO ist, wie das bei einem Pi-PCB+ESP8266 der Fall ist)...
Es gilt ab der Schnittstelle, mit der man sich ins System einklinkt, und die ist wohl (Achtung, Halbwissen ;)) ziemlich nah an der Funkschnittstelle. Und da die CCU kein Open Source ist und eq-3 wenig Motivation hat, an der Schittstelle was zu ändern, gelten diese Vorgaben für die ganze Strecke ab der CCU.
Na ja, ich kapiere es halt vermutlich einfach mal wieder nicht:
Der hier in Rede stehende AP wird doch nicht unbedingt über WLAN eingebunden, das geht auch via LAN, oder? Da sind die Latenzen zwar auch gegeben, aber eben tendenziell deutlich besser (was die Laufwege zwischen dem Prozessor für z.B. DebMatic und der eigentlichen Funkschnittstelle (auf dem AP) betrifft; ob das für die "magischen 5ms" in toto reicht (https://forum.fhem.de/index.php/topic,97295.msg905065.html#msg905065) kann ich nicht beurteilen, und ob das auch (noch?) gilt, wenn man ein "intelligentes" abgesetztes IO nutzt, ist eine weitere Frage.
Vermutlich hast du aber dahingehend recht, dass die DebMatic (das dürfte wenn, dann die besten Aussichten auf Erfolg bieten) irgendwo eine Art "Identitätsspeicher" haben muss, um den "Master-Key" für das ganze zu speichern. Dass dafür uU. ein "entferntes IO" nicht taugt, kann durchaus sein - das war afaik auch bei BidCoS nicht wesentlich anders - da konnte man ihn aber irgendwo eintragen.
Bin mal gespannt, ob unsere cracks@hm da irgendeinen Weg finden, das Ding "solo" nutzbar zu machen, ansonsten scheint es ja auch keine schlechte Idee zu sein, so ein Teil zur Reichweitenvergrößerung einzusetzen...
Aber jetzt wirklich: habe fertig ;D
(Wollte doch eigentlich nur anmerken, dass es für einen noob keine gute Idee ist, sich auf experimentelles Eis zu begeben ::) ... Man kann da zwar unheimlich viel lernen, aber das Risiko ist eben hoch, dass man über irgendwas stolpert ;D .)
Ich bin ja bei Dir, dass es technisch möglich sein müsste, den AP als HMIP-IO-Device zu nutzen. Aber das Szenario wird von eq-3 nun mal nicht unterstützt. Und um das an eq-3 vorbei zu machen, kann man zwar das Funkmodul über (W)LAN/USB oder was auch immer absetzen, nur muss man dann für die ganze Strecke die gleichen Vorgaben erfüllen, die für das Funkmodul alleine gelten, wenn es direkt an der CCU hängt. Das hat der Alex zwar auch geschafft mit seinen Platinen, aber man kann nicht zu lange Kabeln oder zu viele Hops dazwischen haben. Eine konkrete Grenze kenne ich nicht, aber ich wollte halt nur Deine Aussagen "irgendein IO" und "was tweaken" relativieren.
Aber von mir aus müssen wir das auch nicht weiter vertiefen, ich wollte nur die akltuelle Lage darstellen.
Dem HmIP AP fehlt insbesondere der RPC Stack der CCU. Daher kann der AP lediglich als LAN Gateway eingesetzt werden. Analog zum BidCos LAN-Gateway. Diese Gateways werden in der CCU konfiguriert. Man kann in der CCU auch bestimmte HM Komponenten diesen Gateways zuordnen. Die Kommunikation läuft dann zwischen Gateway und HM Komponente.
Für einen RPC Client (wie HMCCU) ist das alles transparent, d.h. single point of contact ist die CCU. Von den LAN-Gateways sieht FHEM/HMCCU nichts (muss es auch nicht).
Um einen HmIP AP als LAN-Gateway nutzen zu können, muss zunächst die CCU auf die neuste Firmware aktualisiert werden. Dann findet man unter Einstellungen > Systemsteuerung den neuen Button "Accesspoints mit inkompatibler Firmware". Damit kann man die Firmware des HmIP APs aktualisieren und anschließend anlernen und als LAN Gateway einrichten.
Kurzfassung also doch:
Geht (ohne weitere Hardware), wenn man z.B. als CCU eine DebMatic (geht auch auf demselben Server) aufsetzt?
Zitat von: Beta-User am 05 November 2020, 20:02:18
Kurzfassung also doch:
Geht (ohne weitere Hardware), wenn man z.B. als CCU eine DebMatic (geht auch auf demselben Server) aufsetzt?
NEIN:
https://homematic-forum.de/forum/viewtopic.php?f=26&t=60444&p=604909#p605804 (https://homematic-forum.de/forum/viewtopic.php?f=26&t=60444&p=604909#p605804)
https://github.com/jens-maus/RaspberryMatic/wiki/Einleitung#vorraussetzungen (https://github.com/jens-maus/RaspberryMatic/wiki/Einleitung#vorraussetzungen):
ZitatHmIPW-DRAP LAN HmIP-Wired Access Point :heavy_check_mark: RPI-RF-MOD notwendig
Zitat von: zap am 05 November 2020, 18:50:20
Von den LAN-Gateways sieht FHEM/HMCCU nichts (muss es auch nicht).
Ich weiß was du meinst, aber natürlich existiert das LAN-GW/der HmIP-HAP als Device:
Internals:
.FhemMetaInternals 1
CFGFN ./cfg.d/general/interfaces/homematic/gateway.cfg
DEF general.interfaces.homematic.gateway.0
FUUID 5fa0156b-f33f-0f53-c1d7-bb0f323643452f86
FVERSION 88_HMCCUDEV.pm:v4.3.12-s21452/2020-03-19
IODev general.interfaces.homematic.ccu3
NAME general.interfaces.homematic.gateway.0
NR 314
STATE <table>
<tr>
<th style="text-align: left;">Duty Cycle</th>
<td>1.00 %</td>
</tr>
<tr>
<th style="text-align: left;">CSMA Level</th>
<td>2.00 %</td>
</tr>
<tr>
<th style="text-align: left;">Erreichbarkeit</th>
<td><span style="color: green";>Erreichbar</span></td>
</tr>
<tr>
<th style="text-align: left;">Lokale Adresse</th>
<td>192.168.0.148</td>
</tr>
</table>
TYPE HMCCUDEV
ccuaddr 0003DB3393B150
ccudevstate active
ccuif HmIP-RF
ccuname general.interfaces.homematic.gateway.0
ccutype HmIP-HAP
channels 1
firmware 2.2.18
statevals devstate
.attraggr:
.attrminint:
.userReadings:
HASH(0x55c71cdc0ec8)
Helper:
DBLOG:
activity:
general.system.log.db:
TIME 1604610940.00926
VALUE alive
carrier_sense_level:
general.system.log.db:
TIME 1604610940.00926
VALUE 2.000000
config_pending:
general.system.log.db:
TIME 1604610940.00926
VALUE false
duty_cycle:
general.system.log.db:
TIME 1604610940.00926
VALUE false
duty_cycle_level:
general.system.log.db:
TIME 1604610940.00926
VALUE 1.000000
install_test:
general.system.log.db:
TIME 1604610940.00926
VALUE true
ip_address:
general.system.log.db:
TIME 1604610940.00926
VALUE 192.168.0.148
reachable_formatted:
general.system.log.db:
TIME 1604610940.00926
VALUE <span style="color
state:
general.system.log.db:
TIME 1604610936.67333
VALUE clear
READINGS:
2020-11-05 22:15:40 activity alive
2020-11-05 22:15:40 carrier_sense_level 2.000000
2020-11-05 22:15:40 config_pending false
2020-11-05 22:15:40 duty_cycle false
2020-11-05 22:15:40 duty_cycle_level 1.000000
2020-11-05 22:15:40 install_test true
2020-11-05 22:15:40 ip_address 192.168.0.148
2020-11-05 22:15:40 reachable_formatted <span style="color: green";>Erreichbar</span>
hmccu:
devspec general.interfaces.homematic.gateway.0
dp:
0.CARRIER_SENSE_LEVEL:
OSVAL 2.000000
OVAL 2.000000
SVAL 2.000000
VAL 2.000000
0.CONFIG_PENDING:
OSVAL 0
OVAL 0
SVAL false
VAL false
0.DUTY_CYCLE:
OSVAL false
OVAL false
SVAL false
VAL false
0.DUTY_CYCLE_LEVEL:
OSVAL 1.000000
OVAL 1.000000
SVAL 1.000000
VAL 1.000000
0.INSTALL_TEST:
OSVAL true
OVAL true
SVAL true
VAL true
0.IP_ADDRESS:
OSVAL 192.168.0.148
OVAL 192.168.0.148
SVAL 192.168.0.148
VAL 192.168.0.148
0.UNREACH:
OSVAL alive
OVAL 0
SVAL alive
VAL false
Attributes:
IODev general.interfaces.homematic.ccu3
alias Hm-IP Accesspoint Obergeschoß
ccureadingfilter .*
ccureadingname 0.CARRIER_SENSE_LEVEL:carrier_sense_level;0.CONFIG_PENDING:config_pending;^0.DUTY_CYCLE$:duty_cycle;0.DUTY_CYCLE_LEVEL:duty_cycle_level;0.INSTALL_TEST:install_test;0.IP_ADDRESS:ip_address
group Zentralen & Gateways
icon hm_ccu@black
room Admin->Interfaces->Homematic
sortby 2100
stateFormat <table>
<tr>
<th style="text-align: left;">Duty Cycle</th>
<td>[$name:duty_cycle_level:d2] %</td>
</tr>
<tr>
<th style="text-align: left;">CSMA Level</th>
<td>[$name:carrier_sense_level:d2] %</td>
</tr>
<tr>
<th style="text-align: left;">Erreichbarkeit</th>
<td>[$name:reachable_formatted]</td>
</tr>
<tr>
<th style="text-align: left;">Lokale Adresse</th>
<td>[$name:ip_address]</td>
</tr>
</table>
userReadings reachable_formatted:activity.+ {
my $reachable = ::ReadingsVal($name, q(activity), undef);
my @values = ($reachable)
? ($reachable eq q(alive))
? qw(green Erreichbar)
: qw(red Nicht erreichbar)
: qw(red Unbekannt);
return sprintf q(<s
Ja klar, es hat eine ganz normale Geräteadresse. In den zugeordneten Geräten findet man auch die Gateway Adresse als Interface.
Wäre vielleicht noch eine nette Funktion für HMCCU, wenn man die Gateway Adresse bzw. die Zuordnung eines Gerätes zu einem Gateway ändern könnte ....
Zitat von: Beta-User am 05 November 2020, 12:00:49
Ich werde mich derweil mit anderem beschäftigen, ich habe da z.B. grade ein paar interessante ZigBee-Devices aus China im Zulauf, z.B. zwei (1 und 2-Kanal-) UP-Aktoren, die man scheinbar in europ. UP-Dosen hinter bestehende Schalter OHNE Nullleiter unterbringen kann (Stück <20 Euro). Da kannst du bei eQ-3 lange warten, bis die sowas in HM-IP anbieten... (Aber bei solchen Experimenten weiß man nie, ob es läuft und wenn ja, wie lange bzw. wie lange es dauert, bis der betr. Aktor in den Interface-Dienst integriert ist).
Gibt es hierzu schon ein Ergebnis? Von wem kann man diese Schalter in China unter welchem Namen kaufen?
Zitat von: McShire am 26 Januar 2021, 16:59:38
Gibt es hierzu schon ein Ergebnis? Von wem kann man diese Schalter in China unter welchem Namen kaufen?
Es gibt ein paar Ergebnisse, siehe dazu den Thread [unboxing] - neue ZigBee-Devices (https://forum.fhem.de/index.php/topic,115963.0.html)
Mit deconz<->HUEDevice läuft (nur) der 2-Kanalige (noch) nicht, (auch wenn ich die beiden Kanäle direkt in deCONZ-GUI doch geschalten bekomme), unter zigbee2tasmota habe ich alle zu schalten bekommen (zwischenzeitlich ist auch ein zweikanaliger mit neutral hier eingetrudelt), so dass ich wetten würde, dass es mit zigbee2mqtt auch ginge.
Bezugsquellen sind schwierig; ich hatte alle in obigem Thread genannten Devices aus unterschiedlichen Quellen geordert, und vermutlich sind das auch nur Distributoren, so dass man sowieso nie sicher sein kann, was man am Ende tatsächlich in die Hand bekommt... (Aber selbst bei dem "without neutral" kam auf meine Fragen schnell eine Antwort! (Ich hatte rückgemeldet, dass das Teil unter deconz nicht will und gefragt, ob die dazu was wüßten; hätten wohl anstandslos getauscht, wenn ich gewollt hätte, obwohl es eher kein HW-Problem war...)).
Kurz: Wenn du entweder ein sehr aktuelles zigbee2mqtt nutzt (oder zigbee2tasmota, was ich nicht guten Gewissens empfehlen kann, das ist selbst mir zu speziell), oder eine Variante mit neutral bestellst, oder selbst in Richtung DE die für die Integration erforderlichen Daten zusammenklauben kannst, dürfte das Risiko gering sein...
Danke für die Info. Ich werde mal versuchen, da etwas zusammen zu bekommen.