[HM-Wired] Entwicklung HBW-SD6-Multikey (haus-bus.de 6fach-Taster)

Begonnen von Thorsten Pferdekaemper, 22 April 2017, 09:10:04

Vorheriges Thema - Nächstes Thema

Viktor Pankraz

#30
Zitat von: Thorsten Pferdekaemper am 15 Mai 2017, 06:33:55
Wenn 0 und 1 bis 255 in einem Byte schon belegt sind, dann gibt es kein "alles andere". Außerdem enthalten "leere" EEPROMs anscheinend lauter 255. D.h. entweder wir nehmen 255 als Default oder 255 darf nicht bei den erlaubten Werten sein. Ich würde vorschlagen, wir lassen nur 1 bis 250 als normale Werte zu.
Einverstanden.

Zitat von: Thorsten Pferdekaemper am 15 Mai 2017, 06:33:55
Das bedeutet: Wenn man das Teil einfach so verwendet, wie es ist, dann sendet es alle 10 Sekunden falls sich der Wert um 50 ändert. Wie stark flattert denn der Wert, wenn nichts angeschlossen ist? Ich würde gerne vermeiden, alle 10 Sekunden einen (dazu noch sinnlosen) Wert über den Bus zu schicken.
Bei nicht angeschlossenem Helligkeitssensor ist der Pegel über den Widerstand an einem definierten Potential und flattert nur einige wenige digits. Sollte bei 50 als default also kein Problem darstellen.
Zitat von: Thorsten Pferdekaemper am 15 Mai 2017, 06:41:46
hier ist jetzt auch die neue XML.
Danke, das geht ja schnell :)

Zitat von: Thorsten Pferdekaemper am 15 Mai 2017, 10:20:45
um welchen DCDC-Wandler geht es denn überhaupt?
Um den DCDC neben dem großen Kondensator auf der Rückseite

Thorsten Pferdekaemper

Zitat von: Viktor Pankraz am 15 Mai 2017, 10:21:31Danke, das geht ja schnell :)
Ja, jetzt hat mich die Erkältung erwischt und um wenigstens Julian und seine Mama schlafen zu lassen bin ich zum Husten schonmal nach unten gegangen...

Zitat
Um den DCDC neben dem großen Kondensator auf der Rückseite
Ah, es geht also nur darum, die Abwärme vom Temperatursensor wegzubekommen. Richtig?

Gruß,
   Thorsten
FUIP

Viktor Pankraz


Thorsten Pferdekaemper

Hi,
vielleicht wäre es da einfacher und zielführender, wenn man einen zweiten Sensor anklemmen kann, den man dann selbst an geeigneter Stelle verlegen kann. Wir könnten dann ja eine Option spendieren, die den zweiten Sensor statt des ersten benutzt.
...oder wir machen halt doch gleich zwei Kanäle dafür. Der Key des ersten ist ja bekannt, da weiß man dann ja, welches der zweite ist. Oder?
Gruß,
   Thorsten
FUIP

ManfredC

Hi Viktor,

Zitat von: Viktor Pankraz am 15 Mai 2017, 10:15:10
Wenn es nur die RS485 Adapterplatine gäbe, würde ich dir ja auch Recht geben. Aber es gibt auch Adapterplatinen, die nur Stecker bestückt haben. Und auf diese müsste ich den DCDC ja auch drauf tun, weil der auf dem Taster selbst fehlt. Diese Adapterplatine ist auch die meist verkaufte (weil eben günstig).

Da frage ich mich warum man den Prozessortaster nimmt, wenn man keinen Bus verwenden will. Dann kann man ja auch den Standard-Taster verwenden.

Grüße,

Manfred

Viktor Pankraz

Zitat von: Thorsten Pferdekaemper am 17 Mai 2017, 08:30:03
vielleicht wäre es da einfacher und zielführender, wenn man einen zweiten Sensor anklemmen kann, den man dann selbst an geeigneter Stelle verlegen kann. Wir könnten dann ja eine Option spendieren, die den zweiten Sensor statt des ersten benutzt.
Der Temperatursensor auf der Platine ist optional und bisher nicht standardmäßig bestückt und der 1-Wire Anschluss ist auch extern verfügbar. D.h. jeder, der kann da einen externen anschließen und dahin legen, wo er messen möchte und es würde bereits mit der aktuellen FW funktionieren. Schöner fände ich natürlich, dass man da mehrere Kanäle anbietet und der Benutzer auch mehrere externe anschließen kann.

Zitat von: ManfredC am 17 Mai 2017, 08:45:09
Da frage ich mich warum man den Prozessortaster nimmt, wenn man keinen Bus verwenden will. Dann kann man ja auch den Standard-Taster verwenden.
Die Homematic version ist ja nicht die einzige die den Prozessor hat, es gibt auch andere Systeme, die den Taster exakt so nutzen (mit anderer FW natürlich). Natürlich kann ich für jeden Anwendungsfall (Bussystem) ein Bestückungsvariante erzeugen und auch eine neue Variante der Adapterplatine anlegen. Dies erzeugt für mich aber zu viel Arbeit und ich kann nicht in geringen Stückzahlen alle Varianten produzieren lassen ohne dass es dann richtig ins Geld geht. Wenn ich allerdings von der Homematic Variante gleich 100-200St. auflegen kann und sie mir garantiert abgenommen werden, kann ich da gerne weiter optimieren :)

QLink

Zitat von: Viktor Pankraz am 17 Mai 2017, 13:14:59
Wenn ich allerdings von der Homematic Variante gleich 100-200St. auflegen kann und sie mir garantiert abgenommen werden, kann ich da gerne weiter optimieren :)

Wenn das Ding stabil funktioniert und du die Verfälschung des Temperaturfühlers noch in den Griff bekommst, denke ich wird das Ding fliegen. :)
Eine gute Anleitung natürlich vorausgesetzt.

Eine Frage: Wenn mein Schalterprogramm(Schrack Visio 50: http://image.schrack.com/datenblaetter/h_ev1xxxxx--_de.pdf) nicht in den aufgeführten dabei ist, welche Möglichkeit hab ich dann den Taster zu integrieren ?

Viktor Pankraz

hmm mit 50mm Innenmaß wird es in der Tat schwierig. Die Tasterplatine ist 54,5x54,5mm und passt wunderbar in viele Schalterprogramme mit 55x55mm Zentralplatten Maße. Den Taster auf 50mm kleiner zu machen wäre ein redesign :(

Viktor Pankraz

#38
Hier übrigens eine aktuelle FW. Sozusagen die erste Version die laufen sollte und folgende Features hat:
- 6 Taster inkl. 30 peering Kanäle
- 6 LEDs inkl. 30 peering Kanäle
- Temperatursensor (aber noch nicht kompensiert )
- Analog-Eingang um Helligkeit zu messen ist noch deaktiviert
- automatisches LED Feedback bei Tastendruck

Würde gerne wissen, ob es in der FHEM Umgebung schon gut funktioniert und stabil eingesetzt werden könnte. Zu hause teste ich noch mit ner CCU2 auf dem PI (https://github.com/leonsio/YAHM)

Nächste FW soll dann noch die von Thorsten gewünschten Blink-Features (BLINK_ON, BLINK_TOGGLE) realisieren.

Viktor Pankraz

#39
Hallo Thorsten,

habe mal eine Direktverknüpfung von Taster:1 und LED:12 angelegt. Dann sehe ich folgenden Datenverkehr zwischen CCU und dem Taster:

I-Nachricht an 0x42FFFFFF von CCU: Daten [20] WRITE_EEPROM address: 40, nrBytes = 16 data = 0 42 FF FF FF B FF FF FF FF FF FF FF FF FF FF
ACK-Nachricht an CCU von 0x42FFFFFF:

I-Nachricht an 0x42FFFFFF von CCU: Daten [20] WRITE_EEPROM address: F0, nrBytes = 16 data = FF FF FF FF 42 FF FF FF 0 B FF C8 0 C8 0 FF 
ACK-Nachricht an CCU von 0x42FFFFFF:

Der erste Schreibbefehl auf Adresse 0x40 und 0xF0 ins Eeprom scheint OK zu sein und die Daten sehen auch plausibel aus.
Aber ich kann die Parameter in der WebUi nicht bearbeiten :( sobald ich auf "Bearbeiten" klicke, bekomme ich nur eine leere Seite angezeigt. Hast du ne Idee? Vielleicht noch etwas in der xml-Datei?

Thorsten Pferdekaemper

Zitat von: Viktor Pankraz am 20 Mai 2017, 22:29:27Würde gerne wissen, ob es in der FHEM Umgebung schon gut funktioniert und stabil eingesetzt werden könnte.
Ich habe vor, das in den nächsten paar Tagen auszuprobieren. Kannst Du mir den schnellsten Weg sagen, wie ich das Hex-File auf das Gerät laden kann?

Zitat von: Viktor Pankraz am 20 Mai 2017, 23:26:22
Der erste Schreibbefehl auf Adresse 0x40 und 0xF0 ins Eeprom scheint OK zu sein und die Daten sehen auch plausibel aus.
Aber ich kann die Parameter in der WebUi nicht bearbeiten :( sobald ich auf "Bearbeiten" klicke, bekomme ich nur eine leere Seite angezeigt. Hast du ne Idee? Vielleicht noch etwas in der xml-Datei?
Eigentlich ist mir persönlich ziemlich egal, was die CCU macht, aber...
Für mich sieht das auch alles gut aus. Die CCU scheint das ganze ja auch erstmal richtig interpretiert zu haben. Hast Du mal nachgeschaut, ob im Log der CCU was ankommt? Also auf die CCU per SSH oder so und dort

tail -f /var/log/messages

Die nötigen Einstellungen solltest Du in der CCU unter "Systemsteuerung-> Sicherheit" finden.

Möglicherweise muss man in der CCU auch irgendeinen Expertenmodus aktivieren.

Gruß,
   Thorsten

FUIP

Thorsten Pferdekaemper

Hi,
ich habe jetzt versucht, das neue hex-file per Flip auf den Taster zu laden. Allerdings scheitere ich am Flip. Wenn ich zur Verbindung "USB" wähle, dann bekomme ich die Fehlermeldung
"AtLibUsbDfu.dll not found"
Wenn man danach im Internet sucht, dann erfährt man, dass das wohl an USB-Treiberproblemen liegt. Tatsächlich nennt mein Win7 das Teil auch "Unbekanntes Gerät" oder so. Allerdings enden alle Versuche, einen Treiber laut der verschiedenen Lösungen zu installieren in einer Meldung, dass schon der optimale Treiber installiert sei.
Ich habe dann den USB-Treiber im "freien" Tool "dfu-programmer" probiert, was auf dasselbe herauslief.
Ich weiß jetzt nicht so recht weiter...
Gruß,
   Thorsten

FUIP

Viktor Pankraz

Also ich habe dies mindestens auf 4 verschiedenen Rechnern getestet, aber dies Problem noch nie gehabt. Ein Unteschied zu dir wird vielleciht sein, dass ich immer vorher noch das Atmel Studio installiert habe. Bei der Installation werden auch USB Treiber installiert. Aber eigentlich sollte es auch ohne gehen:
Ich habe immer dieser Variante FLIP 3.4.7 for Windows (Java Runtime Environement included) installiert. Welche hattest du?

ah was mir noch gerade einfällt. Hast du auch den Bootloader gestartet (grüne und rote LED auf der Rückseite blinken im Wechsel)? Hier www.haus-bus.de/wiki/index.php/Produktbeschreibung_SD6 ist beschrieben, wie du den Bootloader startest und hier http://www.haus-bus.de/wiki/index.php/HowTo_Eigene_Firmware_laden ist die Beschreibung wie die FW geladen werden muss.

Thorsten Pferdekaemper

Zitat von: Viktor Pankraz am 21 Mai 2017, 22:57:57Hast du auch den Bootloader gestartet (grüne und rote LED auf der Rückseite blinken im Wechsel)? Hier www.haus-bus.de/wiki/index.php/Produktbeschreibung_SD6 ist beschrieben, wie du den Bootloader startest
Das mit der Taste 6 hatte ich nicht gesehen. Ich werd's mal heute abend probieren.
Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

Hi,
also erst einmal die gute Nachricht: Ich habe es jetzt geschafft, die neue Firmware aufzuspielen, das ganze funktioniert im Prinzip in FHEM und Peerings funktionieren im Prinzip auch.

Nachdem ich die Taste 6 vor dem Einstöpseln gedrückt hatte, kam tatsächlich das rot/grüne Blinken. Die Fehlermeldung kam in Flip aber trotzdem noch. Allerdings taucht das Teil im Geräte-Manager jetzt unter "Andere Geräte" auf und ich konnte den Treiber per "Treiber aktualisieren" nachinstallieren.
Das eigentliche Flashen ging dann so schnell, dass ich mir nicht sicher war, ob es auch geklappt hat. Die Rückmeldung vom Flip sind ja nicht sooo der Hit.

In FHEM hatte ich zuerst mit dem Peering ebenfalls Probleme. Die hier drangehängte XML hat's dann gefixt. Möglicherweise funktioniert das auch für die CCU. Anscheinend muss man doch bei jedem Peering-Parameter ein Default angeben.

Getestet habe ich in FHEM was mir halt so einfiel. Das kam dabei raus:

  • Das LED-Feedback konnte ich nicht abschalten.
  • Peerings funktionieren im Prinzip intern und extern, aber...
  • Lange Tastendrücke gehen raus, aber reinkommende (oder auch interne) bewirken nichts
  • Die Level-Settings zu den Peerings bewirken nichts. Peerings setzen immer auf 100% bzw. 0%.
  • Peerings, bei denen ein Taster vom SD6 einen externen Aktor schalten soll, sind irgendwie unzuverlässig. Ich glaube, dass das daran liegt, dass die HMW-Originale nicht nur ein ACK zurückliefern, sondern eine komplette I-Message. Darauf erwarten sie dann aber wieder ein ACK vom SD6, welches nicht kommt. Es kann sein, dass das noch ein Problem in meiner Lib ist, aber ich kann mich daran erinnern, so etwas in der Art schon einmal gelöst zu haben
  • Ich habe die Vermutung, dass der SD6 manchmal sendet, obwohl der Bus nicht frei ist. Da bin ich mir aber noch nicht sicher.
So, das war's jetzt erstmal.
Gruß,
   Thorsten




FUIP