Homematic Wired - Homebrew Devices

[Dirk]

Wir haben die Zeit in der Hand, die vom Eintreffen der Discovery-Message bis zum Raussenden des F8 vergeht. Was ist aber mit der Zeit, bis die Discovery-Message wirklich beim jeweiligen Device ankommt?

In der Zeit müssen wir nix machen. Oder wie meinst du das?

Der Default-Wert für "Long press" liegt bei 2 Sekunden. Wie kann ich nach 2 Sekunden nachträglich alle 300ms ein Event schicken???

Wie nachträglich?
Wenn du länger als longPressTimeout (default 2 Sekunden) drückst, dann werden alle 300ms KeyEvents gesendet.
shortPressEvents werden nur nach dm Loslassen gesendet. Und nur, wenn longPressTimeout noch nicht erreicht ist.

Ich habe das noch nicht ausprobiert, aber ich glaube, dass die Untergrenze für LONG 400ms ist.

Das ist abhängig vom Device und sollte in der XML-Datei stehen.
Beim hmw_io12_sw7_dr z.B. ist es Default 2s, Min 0,1s, Max 25,5s

[Thorsten Pferdekaemper]

In der Zeit müssen wir nix machen. Oder wie meinst du das?

Ich meine es so: Angenommen wir haben zwei Devices. Eins hängt im Schaltschrank direkt neben dem LAN-Adapter. Zum anderen gehen 200m Leitung und es hängt noch ein Leitungstreiber dazwischen. Dann kann ich mir schon vorstellen, dass sich da ein paar Mikrosekunden Unterschied ergeben, bis das Signal von der Zentrale beim Device ist.

Wie nachträglich?

Wenn ich erst nach 2000ms weiß, dass es ein LONG ist, dann kann ich nicht von Anfang an alle 300ms Nachrichten schicken. Ich kann erst bei 2000ms anfangen.

Wenn du länger als longPressTimeout (default 2 Sekunden) drückst, dann werden alle 300ms KeyEvents gesendet.
shortPressEvents werden nur nach dm Loslassen gesendet. Und nur, wenn longPressTimeout noch nicht erreicht ist.

Das ist mir jetzt auch klar. Ich werde das auch noch ändern, ich kann nur nicht versprechen, dass es heute schon soweit ist.
Gruß,
    Thorsten

[Dirk]

Ich meine es so: Angenommen wir haben zwei Devices. Eins hängt im Schaltschrank direkt neben dem LAN-Adapter. Zum anderen gehen 200m Leitung und es hängt noch ein Leitungstreiber dazwischen. Dann kann ich mir schon vorstellen, dass sich da ein paar Mikrosekunden Unterschied ergeben, bis das Signal von der Zentrale beim Device ist.

Die Signale gehen mit Lichtgeschwindigkeit über die Leitung. Bis man hier Verzögerungen im µs-Bereich mitbekommt, könnte die Leitung schon recht lang werden. Im ms-Bereich noch vieeeeeel länger.
Was für Leitungstreiber hast du noch dazwischen. Von der Zentrale zu den Devices sollten keine weitere Hardware im Bus sein.
Mit Ausnahme des Interfaces.

Wenn ich erst nach 2000ms weiß, dass es ein LONG ist, dann kann ich nicht von Anfang an alle 300ms Nachrichten schicken.

Die Events kannst du natürlich erst nach Ablauf der 2000ms Senden.

Gruß
Dirk

[Thorsten Pferdekaemper]

So, ich habe gerade die neue Version eingecheckt. Die Tastendrücke sind jetzt korrigiert und es reagiert wie Dirk es beschrieben hat. (Mit longPressSchwelle fix auf 2000ms.)

• 0-49 ms: nix passiert
• 50-longPressSchwelle: nach Loslassen -> kurzer Tastendruck
• > longPressSchwelle: alle 300ms keyEventLong, Wiederholungen müssen mit selben keyEventCounter gesendet werden. Sonst gibt es probleme beim Dimmen

Ich kann allerdings die LONG Wiederholungen im FHEM Event Monitor nicht sehen. Anscheinend wird nur ein Event getriggert, wenn sich der Key Counter ändert. 

Ich vermute das ist ein Bug. Pasiert das auch, wenn du RAW-Messages schickst?

Das bezieht sich auf die "leeren Messages" wenn man per FHEM einen Aktor schaltet (also direkt mit "set ... on"). Wenn ich das per "set ... RAW" mache, dann funktioniert das so, wie ich erwartet habe. Die Zentrale schickt das Kommando, mein Device antwortet mit dem neuen Wert des Aktors und die Zentrale sendet daraufhin ein ACK. Keine seltsamen leeren Messages.

EDIT: Ich habe jetzt noch eine neue Version hochgeladen. Jetzt werden auch ACKs gesendet. Dadurch geht das Schalten per FHEM auch etwas schneller (aber der Bug oben sollte schon noch gelöst werden).

[Thorsten Pferdekaemper]

So, hier das heutige Update: In der aktuellen Version sind zwei Kleinigkeiten korrigiert:

• Die Firmware-Version wird richtig übertragen (momentan 0.01).
• Das Modul antwortet nicht mehr auf Broadcast-Messages. (Außer in Zukunft auf "z" bzw. "Z" sowie Discovery.)

Mir fallen während meiner Versuche immer wieder kleine Fehler in der FHEM-Integration auf. Kümmert sich darum momentan noch jemand oder ist das verwaist? Falls letzteres zutrifft, würde ich mich ggf. selbst darum kümmern. Man muss doch einiges mit set..RAW ausprobieren.

Ansonsten: Gibt es eigentlich Wünsche, was am HMW-Modul vorranging eingebaut werden soll? Ich meine damit: Womit soll es weitergehen?

Gruß,
    Thorsten

[Dirk]

Hi Thorsten,

Ich kann allerdings die LONG Wiederholungen im FHEM Event Monitor nicht sehen. Anscheinend wird nur ein Event getriggert, wenn sich der Key Counter ändert. 

Ja, Das hatte ich aktuell so gebaut.

Das Modul antwortet nicht mehr auf Broadcast-Messages. (Außer in Zukunft auf "z" bzw. "Z" sowie Discovery.)

Ich muss mal prüfen ob das nicht noch mehr Befehle sind wo das Device auch auf Broadcast hören sollte.

Mir fallen während meiner Versuche immer wieder kleine Fehler in der FHEM-Integration auf.

Die kannst du mir gerne mal schicken.

Kümmert sich darum momentan noch jemand

Im Prinzip ja, auch wenn ich aktuell nur langsam weiter komme.

Ich war ja vor 2 Wochen beim Homematic-Usertreffen.
Dort habe ich unter anderem auch die Entwickler von Homegear kennen gelernt. Auch ein OpenSource Projekt bei welchem die HM-Wired integration schon deutlich weiter ist. Laut Entwickler vollständig.
Daher bin ich grade etwas hin und her gerissen wie ich die Entwicklung weiter führe.
Im Prinzip kann man Homegear jetzt schon per XML-RPC mit FHEM kommunizieren lassen.
Die Module existieren. Das Ganze läuft auch auf ARM und X86 Umgebungen.

Gruß
Dirk

[Thorsten Pferdekaemper]

Ich muss mal prüfen ob das nicht noch mehr Befehle sind wo das Device auch auf Broadcast hören sollte.

Das ist kein großes Problem. Die meisten Befehle sind ja sowieso noch nicht implementiert. Wenn wieder einer dazukommt, dann ist es im Coding relativ einfach, das zu entscheiden.

Die kannst du mir gerne mal schicken.

Per PN/Mail oder hier? Folgendes habe ich gerade im Kopf:

• Bei set... werden "leere" Nachrichten geschickt. (Siehe vorherige Posts.)
• Bei Keys steht bei STATE ""
• Wenn man bei einem Key-Channel etwas ändert (INPUT_TYPE, ich glaube aber auch bei LONG_PRESS_TIME), dann wird immer INPUT_LOCKED auf "yes" gesetzt. Dann geht bei einem Original-Device tatsächlich nichts mehr. Man bekommt das nur noch per set...RAW weg.

Dort habe ich unter anderem auch die Entwickler von Homegear kennen gelernt. Auch ein OpenSource Projekt bei welchem die HM-Wired integration schon deutlich weiter ist. Laut Entwickler vollständig.
Daher bin ich grade etwas hin und her gerissen wie ich die Entwicklung weiter führe.
Im Prinzip kann man Homegear jetzt schon per XML-RPC mit FHEM kommunizieren lassen.
Die Module existieren. Das Ganze läuft auch auf ARM und X86 Umgebungen.

...oder man installiert eine CCU (?).
Klar, das ist immer frustrierend, wenn man was entwickelt und dann gibt es das schon. Das führt leicht dazu, das man gar nichts mehr macht. Zumindest sollten wir entscheiden, was in FHEM funktionieren sollte und was per CCU/Homegear. Mir scheint, dass FHEM auf jeden Fall in Sachen Integration besser ist. Meiner Meinung nach sollte FHEM daher HMW-Module direkt schalten bzw. abfragen können. Die ganzen Einstellungen können wir auch (vorerst?) per Homegear/CCU machen.
Wäre so etwas vorstellbar?
Gruß,
    Thorsten

[Dirk]

Hi Thorsten

Per PN/Mail oder hier?

Vielleicht auch im Isuetracker vom Githiub.
Dann währ alles beisammen.

Klar, das ist immer frustrierend, wenn man was entwickelt und dann gibt es das schon. Das führt leicht dazu, das man gar nichts mehr macht.

So schlimm sehe ich das gar nicht. Ich habe die Entwickler vor 2 Wochen auf dem Homematic-Usertreffen kennengelernt und bin mit denen in Kontakt. Auch konnte deren Entwicklung von meiner Doku profitieren. Ebenso konnte ich einige noch unklare Fragen beantworten. Daher sehr ich die Entwicklung positiv.
Homegear ist auch kein vollständiges HA-System. Es fehlt hier z.B. das Frontend.

Mir scheint, dass FHEM auf jeden Fall in Sachen Integration besser ist.

Da bin ich mir noch nicht so sicher. Aktuell aber ja. Im Prinzip würde sich Homegear ähnlich wie ein Inferfaceprozess, also z.B. dem HM485d verhalten.

...oder man installiert eine CCU (?).

Der große Vorteil von FHEM oder auch Homegear ist ja gerade der, das es Opensource ist.
Auch wenn EQ-3 gerade dabei ist die Binaries der CCU für andere Plattformen für die Fremdnutzung freizugeben, wird es zumindest die nächste Zeit keine Sourcen davon geben.

Wäre so etwas vorstellbar?

Durchaus.
Evtl. hast du Zeit dir das mal anzusehen. Dann könnte man das gemeinsam entscheiden.

Gruß
Dirk

[Franz74]

Hallo Jungs,

erst einmal super was ihr hier leistet!

Weil ich in diesem Thread nach der Frage welche Aktoren / Sensoren wir brauchen könnten gelesen habe würde ich mir gerne folgenden Sensor wünschen:

Als Homematic CCU nutzer wäre ein HM Wired auf 1-Wire Adapter um damit Counter und Temperatur Sensoren ins HM System zu bekommen eine Geniale Komponente!

Ich weiß das es schon für FHEM direkt eine 1-Wire Integration gibt aber für eine CCU gibt es keine "schöne".

So könnte ich meinen Heizraum in dem schon HM Wired ist auf 1-Wire umstellen und das wäre mir auch was Wert!

Franz

[Thorsten Pferdekaemper]

Vielleicht auch im Isuetracker vom Githiub.

Erledigt. Es gibt jetzt bei FHEM-HM485 drei neue Issues. Ich denke, dass das dorthin gehört.

Durchaus.
Evtl. hast du Zeit dir das mal anzusehen. Dann könnte man das gemeinsam entscheiden.

Kann ich machen, aber das dürfte ein paar Tage dauern.

erst einmal super was ihr hier leistet!

Danke!

Weil ich in diesem Thread nach der Frage welche Aktoren / Sensoren wir brauchen könnten gelesen habe würde ich mir gerne folgenden Sensor wünschen:

Es war ein bisschen anders gemeint, aber ok.

Als Homematic CCU nutzer wäre ein HM Wired auf 1-Wire Adapter um damit Counter und Temperatur Sensoren ins HM System zu bekommen eine Geniale Komponente!

Ich weiß nicht, ob ein allgemeiner Adapter wirklich machbar ist. Zumindest müsste man dann neue Gerätetypen erfinden mit XMLs usw. Was aber gehen dürfte wäre folgendes: Man sucht sich einen möglichst passenden existierenden Gerätetyp aus und baut dann ein Gerät, welches so tut, als ob es so eins wäre. In dem Fall hier würde sich vielleicht ein HMW-IO-12-Sw14-DR anbieten.  Das Ding hat 6 Analog-Eingänge. Die Auflösung scheint nicht gerade so großartig zu sein, aber für eine Temperaturmessung müsste es ausreichend sein. Statt A/D-Wandler könnte man in der Firmware ja direkt 1-Wire Sensoren abfragen.
Allerdings habe ich kein 1-Wire und weiß nicht wirklich, ob das sinnvoll ist.

Gruß,
   Thorsten
 

[Dirk]

Erledigt. Es gibt jetzt bei FHEM-HM485 drei neue Issues. Ich denke, dass das dorthin gehört.

Super Danke.

Ich weiß nicht, ob ein allgemeiner Adapter wirklich machbar ist. Zumindest müsste man dann neue Gerätetypen erfinden mit XMLs usw. Was aber gehen dürfte wäre folgendes: Man sucht sich einen möglichst passenden existierenden Gerätetyp aus und baut dann ein Gerät, welches so tut, als ob es so eins wäre. In dem Fall hier würde sich vielleicht ein HMW-IO-12-Sw14-DR anbieten.  Das Ding hat 6 Analog-Eingänge. Die Auflösung scheint nicht gerade so großartig zu sein, aber für eine Temperaturmessung müsste es ausreichend sein. Statt A/D-Wandler könnte man in der Firmware ja direkt 1-Wire Sensoren abfragen.

Ich hatte das mit Franz74 schon besprochen.
Das ist auch relativ einfach machbar.
Einen neuen Device-Type mit XML braucht man natürlich.
Beim Universalsensor hab ich das ja schon mal umgesetzt.
Die Idee von dem 1-Wire Teil währ dann z.B. n Temperaturkanäle zur Verfügung zu stellen.
Damit man über den HMW-Bus nicht ständig pollen muss, könnte der AVR das Pollen der 1-Wire Sensoren übernehmen.
Bei Abweichungen von z.B. 0.5 Grad wird über den HMW-Bus dann ein Event geschickt.
Im Idealfall kann man die Abweichung natürlich einstellen.

Gruß
Dirk

[Franz74]

Hallo Dirk, Thorsten,

sorry wenn ich mich in euren Thread einmische, aber es ist mir ein Bedürfnis euch zu sagen wie wichtig eure Arbeit für mich und jeden Homematic Besitzer ist.

Weil ihr endlich Aktoren / Sensoren neben EQ3 entwickelt und dank eurer Basisarbeit auch andere welche Entwickeln können da sich EQ3 weigert so sinnvolle Aktoren wie z.B. einen Wired LED Dimmer zu entwickeln. Für jeden HM Besitzer kann ein zweiter (oder dritter...) Hersteller von Komponenten nur von Vorteil sein!

Jeder der HM Wired einsetzt hat aktuell die Wahl bei den wenigen Aktoren von HM zu bleiben oder auf ein anderes System umzusteigen, das finde ich sehr Schade weil gerade bei Neubauten kommt für mich nur Wired in Frage...

LG

Franz

PS: Vielleicht ließt EQ3 ja mit und kurbelt die Entwicklung von Wired etwas an, sonst macht es die Community und holt sich das Geschäft!

[Thorsten Pferdekaemper]

Einen neuen Device-Type mit XML braucht man natürlich.

Ok, könntest Du mir mal so ein XML zusammenbasteln? Ich schau dann mal, ob ich dazu eine passende Firmware machen kann.

Die Idee von dem 1-Wire Teil währ dann z.B. n Temperaturkanäle zur Verfügung zu stellen.
Damit man über den HMW-Bus nicht ständig pollen muss, könnte der AVR das Pollen der 1-Wire Sensoren übernehmen.

Ich habe bisher noch nichts mit 1-wire gemacht. Was genau müsste ich mir bestellen, damit ich das mal ausprobieren kann? (Das ist kein Versprechen...) Das ganze klingt ja schon sehr interessant. Wenn das mit dem XML wirklich klappt, dann könnte man z.B. sowas wie einen 25-Kanal 1-wire Temperatursensor bauen...

Bei Abweichungen von z.B. 0.5 Grad wird über den HMW-Bus dann ein Event geschickt.
Im Idealfall kann man die Abweichung natürlich einstellen.

Das wäre dann der nächste Schritt...

sorry wenn ich mich in euren Thread einmische,

Das ist ein Forum, ich hoffe, dass sich auch andere "einmischen".

Weil ihr endlich Aktoren / Sensoren neben EQ3 entwickelt und dank eurer Basisarbeit auch andere welche Entwickeln können da sich EQ3 weigert so sinnvolle Aktoren wie z.B. einen Wired LED Dimmer zu entwickeln. Für jeden HM Besitzer kann ein zweiter (oder dritter...) Hersteller von Komponenten nur von Vorteil sein!

Tja, das klingt ja so, als ob Du da sogar kommerzielles Potential siehst. Interessant...
Es wäre auch interessant, wie eq-3 darauf reagieren würde. Entweder sie fangen an, dagegen vorzugehen oder sie begrüßen die Vergrößerung ihres "Ökosystems" sogar. Naja, momentan ist das aber noch nicht wirklich relevant.

Gruß,
    Thorsten

[Franz74]

Hallo Thorsten, Dirk,

also nach meiner Begegnung mit EQ3 auf dem Homematic Usertreffen kann ich nur sagen das sie solange nicht gegen jemanden Vorgehen werden solange dieser die Produkte nicht Kommerziell vertreibt. Da aber beide Projekte hier die RF und hier das Wired keinen Code von EQ3 einsetzen und die Funkkomunikation als solches ja nicht Patentgeschützt sein kann wird es EQ3 nicht leicht haben das zu verhindern.

Ich würde es aber begrüßen wenn ELV (EQ3 ist einen 100% ige Tochter von ELV --> die haben den selben CEO..) sich darauf besinnt das sie von Bastler gegründet und mit Basteler so groß geworden sind wie sie heute sind! Die Entwicklung das sie die Binarys der CCU2 für verschiedene Systeme Freigeben (Projekt OHCU) werden ist schon mal der erste Schritt in diese Richtung und wir können nur hoffen das auch die Sourcen Freigegeben werden.

Und ja ich sehe da sehr viel Potential in der Entwicklung von HM Kompatiblen Aktoren / Sensoren!

• Rafstore Aktor welcher einerseits in Prozent die Behanghöhe und mit einem zweiten Prozentwert die Lamellenstellung Einstellen kann.
• Pool Aktor / Sensor welcher mit Temperatur, PH und auch ORP Sensoren neben der Pool Umwälzpumpe auch die Pool Chemie im Auge behält bzw. sogar mit Dosierpumpen Automatisch Nachregelt
• Dimmer für alles und jeden zweck

Um nur einige zu nennen...

1-Wire ist die billigste Lösung um Temperaturen Digital über einen Bus zu messen, es gibt z.B. Temperaturfühler bei dx.com um EUR 3,60 oder bei Ebay habe ich schon 5 Stück um EUR 7,50 gesehen, dieser werden mit 5V Parasitär über den Stern oder Serienbus versorgt und vom Busmaster gepoolt abgefragt, wobei sich jeder Sensor mit seiner Seriennummer und der Temperatur meldet.

@Thorsten, wenn du einen 1-Wire Fühler haben willst so schreib mir eine PN mit deiner Adresse und du bekommst Post!

LG

Franz

[Thorsten Pferdekaemper]

Hi,
ich wollte gerade mal wieder anfangen, die Konfiguration über's EEPROM einzubauen. Dabei habe ich ein kleines Problemchen, was denn das beste Design wäre. Es steht zur Auswahl:

• Am Anfang, bei Reset (0x21) oder "Konfiguration neu lesen" (0x43) das EEPROM auslesen und die jeweiligen Werte in Variablem im SRAM kopieren. Das kostet beim HMW-LC-SW2-DR schon fast 1kByte, also schon die Hälfte des SRAM. Das ist etwas hässlich.
• Die entsprechenden Werte bei Bedarf lesen. (EEPROM.read() kann man ja so oft machen, wie man will.) Hier kann ich mir Probleme vorstellen, wenn die Zentrale per 0x57 (W) Konfigurationsdaten in mehreren Päckchen schreibt. Dann wird wahrscheinlich erwartet, dass das Modul das erst übernimmt, wenn ein 0x43 hinterherkommt. Oder?

Was meint ihr?
Gruß,
    Thorsten