-
-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Entries in port mapping configuration to support Haus-Bus.de components #2940
Comments
I guess you are referring to the HA Addon. Erwin of RaspberryMatic, right? So please explain in more detail what these additional port bindings are actually necessary for end why you and your solutions require them to be opened or accessible from outside the addon boundaries. This, more technical details please. |
was genau musst du über die angegebenen Angaben hinaus wissen?
Wir haben eine Integration für die Haus-Bus.de Module ähnlich wie CuxDaemon vorgenommen.
Dabei kommuniziert ein Dienst mit unseren Modulen per UDP Port 5855.
Darüber hinaus gibt es einen Admin der über http 8911 erreichbar sein müsste.
|
Hab mir einmal eure Informationen bzgl. eurer Homematic/CCU Unterstützung angeschaut (https://haus-bus.de/?showIntegration=homematicip) und verstehe jetzt schon etwas mehr was ihr da interessantes treibt :) Etwas mehr Dateilinformationen wären für die Allgemeinheit jedoch ggf. weiterhin hilfreich ohne das man einen Java decompiler gegen eurer Addon laufen lassen müsste. Warum und was genau kommunizieren die hausbus geräte über den rückkanal via UDP 5855 mit dem Addon? Welches Protokoll wird hier konkret eingesetzt? Und bzgl. Port 8911 ist mir nun auch klar, das ihr da einfach einen HTTP Server zur Administration abgelegt habt. Eine Frage wäre jedoch warum ihr nicht einfach den internen Webserver der CCU samt Authentifizierungsmöglichkeiten dort verwendet? Soweit ich in eurem YouTube Video sehen konnte erfolgt der Zugriff komplett ohne Authentifizierung, d.h. jeder der Zugriff auf Port 8911 hat kann hierbei jetzt auch z.B. die CCU Neustarten lassen. Das stellt natürlich z.B. eine gewisse Sicherheitslücke dar. Hier könnte/sollte das IMHO in Zukunft bitte am besten mit der Abfrage der credentials gegenüber der CCU abgesichert werden. Das aber nur ebenbei. Bzgl. des dort frei herunterladbaren Addons wäre es schön dieses bitte wie eure Projekte für das ioBroker Addon und die Homeassistant Integration auch das CCU/RM Addon als Projekt unterhalb eurer hausbus GitHub Organization (https://github.com/hausbus) frei verfügbar und am besten in einer entsprechenden OpenSource Lizenz (z.B. Apache 2.0) für jedermann anzubieten damit diesbzgl. dann auch PullRequests mit ggf. Sicherheitsverbesserungen einsenden kann. Dies sollte am besten aus sicht eines OpenSource Projektes wie RasberryMatic auch gleich den Java Quellcode eures Addons beinhalten damit da entsprechend auch hier in Zukunft ggf. etwas zurückfließen kann. P.S: Und bitte nicht via Email antworten sondern die GitHub Webseite direkt nehmen, sonst kommt eure Nachricht samt gequotetem Text im Issue Ticket so auch an. |
Unsere Module sprechen unser hauseigenes Protokoll per UDP zum Dienst, der auf der CCU läuft. Dieser meldet der Homematic Logikschicht alle Events und nimmt Schaltbefehle entgegen |
Hi Jens, hast du eine Idee wieso unser Java Prozess nicht gestartet wird? Funktioniert auf einer CCU oder nem Raspberry ganz normal, aber beim Homeassistant Addon wird der nicht gestartet. Wenn man in zu Fuß aus init.de aufruft, dann läuft er. Gibt es da irgend ein special? |
Das gehört hier eigentlich nicht her, sondern in einen separaten Diskussionsbeitrag, damit auch andere etwas von dieser Info haben. Aber gut, ich beantworte es erst einmal hier. Der Punkt ist: Ein HomeAssistant Addon verhält sich etwas anders als ein normaler Docker Container auf einem "normalen" Docker Host wie einem RaspberryPi oder innerhalb eines Ubuntu Linux. Und so verhält sich das Addon auch etwas anders als ein RaspberryMatic auf einem dedizierten RaspberryPi oder in der CCU3. Der konkrete Unterschied ist, das Home Assistant bei jedem Addon start den Container komplett neu generiert. D.h. also es schmeisst im Grunde das gesamte rootfs weg und generiert es neu aus dem gecachtem Image. Lediglich das Für dein/euer Addon bedeutet das also, das ihr eben nicht davon ausgehen dürft das eure Modifikationen am rootfs (/) (die ihr via Damit ihr aber trotzdem z.B. Anpassungen/patches an der Alles in allem liegt es also an eurem Addon bzw. an der Art&Weise wie eure Addon-Installations- und Startroutinen ablaufen und es braucht ein paar Modifikationen. Von Vorteil wäre es natürlich (wie ich bereits erwähnt hatte) wenn ihr hier auf GitHub auch euer CCU Addon entsprechend freigeben würdet damit man euch dann entsprechende PullRequests und Bugreports diesbzgl. zukommen lassen kann. |
Danke Jens, das hatte alle genau wie von dir beschrieben geklappt. Außer eine Kleinigkeit. Das Neustarten unseres Addons aus unserem Adminbereich funktioniert nicht mehr. Da hat unser Javaprogramm vorher /etc/init.d/S60HausBusDeInterface restart aufgerufen hat und jetzt /usr/local/etc/config/rc.d/hausbusdeip restart. Der Prozess beendet sich, aber wird nicht mehr neu gestartet. Daneben brauchen wir nur noch die Ports. Gibts es eine Möglichkeit, dass die ich Ports vorab irgendwie manuell öffne, damit ich unsere Integration testen kann ? |
Wie vorher bereits angedeutet: Das ganze hier ist ein Geben und Nehmen. Und da ihr ein kommerzieller Akteur seid die damit Geld verdienen was hier mit viel privater Zeit völlig für Lau entwickelt wird, wäre es schön ihr würdet nicht nur "nehmen", sondern eben auch etwas an die Community zurückgeben bzw. euch mehr im Bereich OpenSource engagieren. Insofern wäre es schön zu sehen das ihr mindestens euer Addon hier bei GitHub bitte unter einer entsprechenden OpenSource Lizenz freigeben würdet, denn das wäre nicht nur das richtige Signal, sondern würde unterm Strich euch auch entsprechend helfen wenn dann eben PullRequests mit Verbesserungshinweisen direkt über GitHub eingereicht werden könnten. |
Ja, das werden wir tun. Die anderen Sachen haben wir ja auch veröffentlicht. Selbst die Firmware. Da diese Integration aber noch recht neu ist, will ich erst noch einige Restarbeiten erledigen |
Gut, dann werde ich eure "Spezialports" einfach mal in die developer/nightly snapshot version vom RaspberryMatic HA Addon aufnehmen und sobald ihr dann das Addon als OSS veröffentlicht habt werde/kann ich das dann entsprechend in die nächste stable version dann übernehmen und dann ist das für jeden verfügbar. Bis dahin könnt ihr dann mit der Developerversion vom HA-Addon das alles entsprechend testen. |
…855/udp) and webui admin port (8911/tcp). This refs #2940.
Hi Jens, Danke! |
Dazu musst du einfach die "Snapshot" Version des RaspberrryMatic HA Addon via Addon-Store installieren statt der stable version. Siehe:
Das müsste man sich im Detail dann anschauen wenn ihr eure neue Addon version freigegeben habt, dann kann man das testen. Und noch viel besser wenn das alles bereits auf github liegt, dann kann man das schneller/sauberer debuggen und euch dann direktes feedback geben. |
Erster Test, war insofern erfolgreich, als dass der Adminbereich jetzt funktioniert und ich auch Daten von den Modulen empfange. Allerdings kann ich noch nicht per Broadcast aus dem Container raus kommunizieren: Hast du ne Idee, wie man die Broadcasts noch ins normale Netz geroutet bekommt ? |
Das wird so einfach nicht gehen. die 172er adressen sind ja im docker netzwerk und da kannst du nicht einfach machen was du willst wie in einem normalen netzwerk. Die Info mit Broadcasts ist ja leider wieder eine neue. Für was genau braucht ihr denn die Broadcasts? |
Die Broadcasts brauche ich für die Gerätesuche. Anschließend geht es ohne weiter.
|
Das hab ich mir schon fast so gedacht. Müsste man sich dann eben detailliert im Addon Container anschauen warum der keine Broadcasts senden kann, bzw. es wird nunmal so sein das er den broadcast ja im internen 172er docker netz machen wird, eure geräte ja aber im LAN (192.168.x.x) liegen werden. Dann ist es nur logisch das er die nicht erreichen kann. Kann gut sein das ihr das ohne solch einen Broadcast lösen müsst um solche virtuellen Umgebungen wie Docker, etc. mit Netzwerk-Bridge zu unterstützen. Das ist/wird im Grunde genau das ähnliche Problem sein wie das man mit dem RaspberryMatic HA Addon nicht einen HmIP-HAP bzw. HmIPW-DRAP nutzen kann (siehe #1373), weil auch diese ähnliches broadcasting nutzen. Dafür bräuchte HomeAssistant endlich die Möglichkeit das die Addons definieren können das sie ein macvlan interface mit einer eigenen separaten IP-Adresse aus dem LAN haben wollen. Das geht aber eben momentan (noch) nicht (siehe home-assistant/architecture#1034) |
Verstehe. Dann muss man im Container die IP von unserer Brücke konfigurieren. Ist auch kein Drama, aber sonst geht halt alles so wunderbar automatisch und ohne jegliche Konfiguration.
|
Hi Jens, Grüße |
Describe the solution you'd like
To support the IP integration of the haus-bus.de components two additional ports need to be mapable to extern.
There are HTTP 8911 and UDP 5855. 5855 is the port used to communicate with the modules and 8911 is the port for the admin.
Describe alternatives you've considered
I searched for options to extend the actual provided port mapping entries. But without luck
Is your feature request related to a problem?
No, new feature
Additional information
No response
The text was updated successfully, but these errors were encountered: