HMCompanion - Schnittstelle zur CCU

[domi]

Hallo Olli,
leider bin ich nicht im Besitz einer CCU. Kann jedoch einen HM-CFG-LAN bieten.
Hab ich das richtig verstanden, dass der Kommunikationsport (2001) und Protokoll für die Funkbefehle derselbe ist wie an der CCU ?
Erschwerend kommt noch hinzu, dass die Liste der verfügbaren Geräte nicht an HM-CFG-LAN Adapter abgerufen werden kann.
Ist eine Modifikation dahingehend möglich, dass HMCompanion die CCU oder einen HM-CFG-LAN Adapter unterstützt? Die fehlende Liste könnte ja beispielsweise in Form einer Textdatei angelegt werden.
Gruß
Domi

[owagner]

Hallo,

HMC kann nicht mit dem LAN-Adapter selbst reden. Was aber geht, ist, den BidCoS-Service, der in der HM-CFG-LAN-Software enthalten ist, auf einem Windows-PC laufen zu lassen und HMC dann mit diesem Service reden zu lassen.

Die Daten, die es nur im WebUI gibt (z.B. die dortigen Gerätenamen) gibts dann natürlich nicht.

Viele Grüße,
Olli

[erik]

Hi,

super Tool - DANKE, zwei kleine Anmerkungen habe ich:

1) Kann man die Schnittstelle irgendwie Passwort Schützen? Finde es uncool, das jeder der den Port kennt, dann an der Schnittstelle kommt. Schön wäre ein zusätzlicher Aufruf des Servers:

java -jar hmcompanion.jar <ip oder hostname der CCU> -server <optionaler Port, ansonsten 6770> <optionales passwort>

Zum Aufruf der Schnittselle müßte dann immer das PW mit angegeben werden.

2) Gibt es die Möglichkeit, die RPC Registrierung an der CCU wieder zu löschen. Mittlerweile wurde der richtige Parameter ja herausgefunden. Gerade bei meinen Spielereien wäre es schön, wenn man diesen wieder löschen könnte und HMCompanion beenden - vielleicht mittels "QUIT", oder sowas??

Danke und Grüße

Erik

[owagner]

Hi,

bittesehr (ein paar aufgelaufene Änderungen, die ich quasi anonym mit dem GUI-Modus schon mitveröffentlicht hatte, sind auch gelistet):

Code: Alles auswählen

V0.9 - Clientverbindungen setzen nun SO_KEEPALIVE
     - REQ unterstützt nun auch die Angabe von Arrays und Strukturen mit der [ Array ] bzw. { key1 value1 key2 value2 }
       Notation
     - GUI-Betriebsmodus zum Setzen der Interface/Roaming-Parameter (einfach ohne Parameter starten)
       
V0.10 - GUI-Modus: Button zum schnellen Refresh der RSSI-Informationen hinzugefügt
      - GUI-Modus: Schnittstellen werden nun in der CCU-Reihenfolge angezeigt, mit dem Default-Interface zuerst
      
V0.11 - GUI-Modus: Buttons zum Setzen aller Devices auf Roaming Off, auf Default == Interface mit dem besten RSSI-Wert
        und Roaming On für alle Fernbedienungen
        
V0.12 - Synchronisationsproblem beim Request-Handling konnte dazu führen, das mehrere schnell hintereinander
        abgesendete "SET" (o.ä.)-Befehle zu einem Deadlock führten
      - Server-Sockets werden nun alle mit SO_REUSEADDR generiert, um schnellen Neustart möglich zu machen
      
V0.13 - Client-Verbindungen benutzen nun unabhängig vom Systemzeichensatz immer UTF-8
        
V0.14 - Optionales Authentifizerungstoken für Client-Verbindungen: Wird HMC mit "homematicip -server 6770 <password>" gestartet,
        werden weitere Befehle nur nach Authentifizerung mit "AUTH <password>" angenommen.

Abmelden bei Beenden gabs schon in V0.8

Viele Grüße,
Olli

[Homecastpvr]

Hallo Allerseits,
ich bin derzeit nicht ganz so tief in der Materie und lese mich grad ein wenig schlau.
Seht es mir nach, wenn ich nicht zum richtigen Thema poste. Ich hole mal kurz aus.
In einem Schulungs / Präsentationsgebäude steuert eine HM ausschließlich Wired Komponenten.
Dies sind insgesammt ca. 45! Schalt-, Dimm- und Jalousieaktoren, die derzeit über je zwei 12 und 19 Tasten FBs gesteuert werden.
Mittlerweile mussten zwei 12er FBs getauscht werden, da diese bis auf das permanent leuchtende Backlight keine Funktion mehr zeigten. Der Austausch einer FB ist ja in wenigen Augenblicken ähm, neee, ich meine natürlich STUNDEN erledigt!
Der Versuch eine zweite 19er FB anzulernen endete im totalen Kommunikationschaos der beiden 19er FBs.
Die neue meldete andauernd Config... und die zuvor funktionsfähige 19er FB meldete nur noch Cod-Err / Rote LED.
Nun Gut, nach dem Tausch der zweiten 19er FB ist das System wieder Fehlerfrei und es stehen endlich keine Servicemeldungen mehr an!
Zu klären wären noch so ein paar Sachen, wie ein nicht funktionsfähige NTP Zeiteinstellung trotz scheinbar freiem Kommunikationsweg zu einigen externen Timeservern.
Sehr enttäuschend war die Erkentniss, dass man eine Gruppe von 10 Wired Dimmern zwar so habwegs brauchbar über einen / mehrere parallele Wired Eingänge steuern kann, dies jedoch über eine Funk FB praktisch unmöglich ist und eine einfache "Direktverknüpfungen" nicht vorgesehen ist. Eine Skriptlösung von ELV / EQ3 hat bei 10 parallel zu steuernden Dimmern einen sehr langsamen, auf einander folgend ruckelnden Dimmvorgang zur Folge.
Bei den Jalousieaktoren, die u.a. in 4 x 4er bzw. einer 16er Gruppen arbeiten (sollen) sieht es ähnlich ernüchternd aus. Diese werden meistens mit einer variablen Verzögerung angesprochen. Halbwegs synchron geht da schon mal garnix.
Sooo, zurück zum Thema. Einerseits bin ich auf der Suche nach einer Lösung die Wired Komponenten von der CCU aus brauchbar synchron als Gruppe anzusprechen und gleichzeitig eine alternative Kommunikationsschnittstelle neben den 12er/19er Fernbedienungen zu haben, die entweder durch eine bereits erhältliche, kommerzielle oder eine eigene Software GUI angesprochen wird.
Da ich persönlich aber eher ein Freund von Hardwarelösungen ohne nennenswerte Bootzeit bin und auf diesem Gebiet auch öfters eigene Mikrocontrollerbasierte Projekte realisiere, könnte ich mir die Fertigung eines eigenen Controlpads vorstellen (sofern die Zeit es erlaubt...), der entweder direkt via RS485 oder via LAN mit den HM Teilnehmern spricht.
Ich habe zwar die RS485-Bus Kommunikation mal belauscht, doch ein offenes / bekanntes Protokoll würde schneller zum Ziel führen. Wenn die Hardware auch noch eine Gruppenadresse hätte...... das wäre ein Traum.
Da mir das Wired Protokoll noch nicht über den Weg gelaufen ist, bin ich für Alternativen ganz Ohr.
Habe jetzt hier einiges über HMCompanion und XML-RPC und und und..... gelesen.
Welche Kommunikationsvariante mit welchen Diensen auf der CCU ist für den Schwerpunkt (nahezu) synchrones ansprechen zahlreicher Wired Komponenten, nach Möglichkeit in Gruppen / Gewerken mit simplen Befehlen geeignet?
Ich hoffe nicht, dass dies zu viele Wünsche auf einmal sind.

Gruß

[chrisu]

Hallo,

Da ich persönlich aber eher ein Freund von Hardwarelösungen ohne nennenswerte Bootzeit bin und auf diesem Gebiet auch öfters eigene Mikrocontrollerbasierte Projekte realisiere, könnte ich mir die Fertigung eines eigenen Controlpads vorstellen (sofern die Zeit es erlaubt...), der entweder direkt via RS485 oder via LAN mit den HM Teilnehmern spricht.
Ich habe zwar die RS485-Bus Kommunikation mal belauscht, doch ein offenes / bekanntes Protokoll würde schneller zum Ziel führen. Wenn die Hardware auch noch eine Gruppenadresse hätte...... das wäre ein Traum.
Da mir das Wired Protokoll noch nicht über den Weg gelaufen ist, bin ich für Alternativen ganz Ohr.

Wenn du selber was basteln willst, das direkt mit den RS485-Komponenten spricht schau dir mal das Protokoll vom HS485 http://www.elv.at/output/controller.asp ... tail2=8988 an...
Wenn du das ELV-Journal 02/2006 rumliegen hast, hast du dort die Protokollbeschreibung drin.
Wenn nicht schick mir ne PN, dann schick ich dir die entsprechenden Seiten...

[Homecastpvr]

Hallo Christian,
danke für die Info. Stimmt, da war mal was im Journal zu HS485. Hab ich mal wieder rausgesucht.
Mir ist auch aufgefallen, dass die HM Wired Komponenten z.T. Hardwaremäßig identisch mit den HS485 Teilen sind, jedoch nicht gleich viel kosten.
Da HS485 meines Wissens nicht kompatibel zur HM Wired ist, habe ich in diese Richtung nicht weiter geforscht.
Dann werd ich mir das Protokoll mal genauer anschauen.
Kann man das "HS485 PC Interface" auch für was sinnvolles am HM Wired Bus gebrauchen?

[chrisu]

Hi,

Mir ist auch aufgefallen, dass die HM Wired Komponenten z.T. Hardwaremäßig identisch mit den HS485 Teilen sind, jedoch nicht gleich viel kosten.
Da HS485 meines Wissens nicht kompatibel zur HM Wired ist, habe ich in diese Richtung nicht weiter geforscht.
Dann werd ich mir das Protokoll mal genauer anschauen.
Kann man das "HS485 PC Interface" auch für was sinnvolles am HM Wired Bus gebrauchen?

Die HMW-Komponenten sind (fast) baugleich zu den HS485.
Die haben nur den Linearregler durch einen Schaltregler und den Atmel auf einen stärkeren getauscht.
Aber das Protokoll haben die übernommen, am Anfang hat man mit der CCU auch noch die HS485-Aktoren steuern können...
Haben die aber dann aus der CCU rausgenommen...

Mit dem "HS485 PC Interface" müsste man eigentlich direkt vom PC die HMW-Module ansprechen können.

[owagner]

Aber das Protokoll haben die übernommen, am Anfang hat man mit der CCU auch noch die HS485-Aktoren steuern können...
Haben die aber dann aus der CCU rausgenommen...

Bis zu welcher CCU-Version ging denn das? Vielleicht braucht man nur die /firmware/hs485types/*-Dateien rüberkopieren...

[chrisu]

Hi,

Aber das Protokoll haben die übernommen, am Anfang hat man mit der CCU auch noch die HS485-Aktoren steuern können...
Haben die aber dann aus der CCU rausgenommen...

Bis zu welcher CCU-Version ging denn das? Vielleicht braucht man nur die /firmware/hs485types/*-Dateien rüberkopieren...

Hatten wir hier schon mal diskuriert: http://homematic-forum.de/forum/viewtop ... 822#p29563
Ich hatte es nur ganz am Anfang mit der 1.000er getestet....

Die dürften aber auch eine kleinigkeit am Protokoll geändert haben, da ich damals die HS485 zwar schalten konnte aber keinen Status zurück bekam...