HBW-Sen-SC8 - Aktuelle Version

Begonnen von pula, 12 Januar 2017, 18:49:27

Vorheriges Thema - Nächstes Thema

Thorsten Pferdekaemper

Hi,
ich habe gerade das Gespräch mit den Leuten von haus-bus.de aufgenommen. Sie sagen, dass sie da dran wären und dass es auf GitHub veröffentlicht werden wird. Weitere Details weiß ich noch keine.
Gruß,
   Thorsten
FUIP

ManfredC

Moin,

ich hab mal so einen Taster bestellt. Leider verwenden sie einen XMEGA, keinen ADUINO kompatiblen Pozessor. Auf GitHub finden sich auch Sourcen aus dem HBW Projekt. Ob das ganze schon irgendwie lauffähig ist: keine Ahnung.

https://github.com/haus-bus/MultitasterSD6/tree/HM-Wired

Es gibt ein Xmegaduino Projekt, aber das scheint schon länger tot: https://github.com/Xmegaduino/Xmegaduino

@Thorsten:

ich kann Dir den Taster gerne zur Verfügung stellen wenn Interesse besteht.

Grüße,

Manfred


Thorsten Pferdekaemper

Zitat von: ManfredC am 09 April 2017, 13:36:10ich hab mal so einen Taster bestellt. Leider verwenden sie einen XMEGA, keinen ADUINO kompatiblen Pozessor. Auf GitHub finden sich auch Sourcen aus dem HBW Projekt. Ob das ganze schon irgendwie lauffähig ist: keine Ahnung.
Glaub ich nicht, da sie irgend eine alte Version verwenden, die nicht so richtig läuft. Damit ist es ganz schön schwierig.

Zitat
ich kann Dir den Taster gerne zur Verfügung stellen wenn Interesse besteht.
Interesse besteht schon, aber wenig Zeit...
Ich hatte gehofft, dass sich die Leute von haus-bus.de nochmal melden, aber anscheinend frickeln die lieber selber dran rum.
Gruß,
   Thorsten 
FUIP

Thorsten Pferdekaemper

Zitat von: Thorsten Pferdekaemper am 09 April 2017, 23:16:19
Ich hatte gehofft, dass sich die Leute von haus-bus.de nochmal melden, aber anscheinend frickeln die lieber selber dran rum.
Inzwischen hat sich doch ein Kontakt ergeben und es sieht ganz gut aus. Wie lange das jedoch dauert kann ich nicht sagen.
Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

Hi,
ich habe zu dem 6fach-Taster jetzt einen eigenen Thread aufgemacht:
https://forum.fhem.de/index.php/topic,70929.msg624430.html#msg624430
Gruß,
    Thorsten
FUIP

Lonie

Hallo Thorsten,

vor lauter Mut und wenig Zeit habe ich mir einen Nano geschnappt und die HBW FW drauf geflashed.

Quelle: https://github.com/ThorstenPferdekaemper/HBWired

Schließe ich diesen an den Bus an wird er tadellos von fhem erkannt und als neues Gerät als HMW_GENERIC angelegt. Wie zu erwarten werden in fhem keine Eingänge angezeigt da noch etwas fehlt. Im nächsten Schritt habe ich die Gerätebeschreibungsdatei unter FHEM/lib/HM485/devices/xml abgelegt und die pm daraus konvertiert

sudo -u fhem perl xmlHelper.pl -inputFile ../Devices/xml/hbw_sen_key_12.xml -outputPath ../Devices


Danach habe ich das Device gelöscht und fhem neu gestartet.
Leider verweigert fhem jetzt den Dienst mit folgendem Eintrag im Log.

2017.05.18 17:37:11 2: autocreate: define HBW_Sen_Key_12_HBW4073471 HM485 42FFFFFF HM485LAN
2017.05.18 17:37:11 2: autocreate: define FileLog_HBW_Sen_Key_12_HBW4073471 FileLog ./log/HBW_Sen_Key_12_HBW4073471-%Y.log HBW_Sen_Key_12_HBW4073471
2017.05.18 17:37:12 3: HBW_Sen_Key_12_HBW4073471: Request config for device 42FFFFFF
Not a HASH reference at FHEM/lib/HM485/Device.pm line 1384.


Lösche ich die xml und pm Datei wieder startet es ohne Probleme.

Hattest du schonmal einen ähnlichen Fall bzw. kannst mir helfen an welcher Stelle ich suchen könnte? Da das Gerät einige im Einsatz haben vermute ich den Fehler auf meiner Seite.

Grüße
Marcel

Thorsten Pferdekaemper

Hi,
hol Dir mal die neueste Version vom HM485-Modul. Also sicherstellen, dass der master-Branch im update list steht und ein update machen.
Dann die neu generierte .pm-Beschreibungsdatei löschen (aber nicht die XML) und vergessen, dass man das Generieren jemals manuell machen musste.
Dann shutdown restart und hoffentlich freuen.
Gruß,
   Thorsten
FUIP

Lonie

Dank dir für die schnelle Hilfe. Das pm File automatisch generieren lassen war die Lösung. Danach lief es, bis auf ein paar kleine Problemchen super. Jetzt muss das ganze nur noch in eine Form gebracht werden die in ner Dose verschwinden kann  ;D


Grüße
Marcel

Thorsten Pferdekaemper

Zitat von: Lonie am 18 Mai 2017, 20:33:55
Dank dir für die schnelle Hilfe. Das pm File automatisch generieren lassen war die Lösung.
Ah, Du hast xmlHelper verwendet, obwohl schon auf der neusten Version.
Ich hab mir da mal einen Merker gemacht:
https://github.com/kc-GitHub/FHEM-HM485/issues/56

Zitat
bis auf ein paar kleine Problemchen
Was denn für welche?

Gruß,
   Thorsten
FUIP

Lonie

Guten Morgen Thorsten,

ja, der war irgendwie da und in den HBW Tutorial ist er auch erwähnt. Deswegen ging ich davon aus dass man hier Hand anlegen muss.


Ich bin mir nicht ganz sicher was der Grund war und kann nur die Auswirkungen beschreiben. Nachdem ich ja etliche erfolglose Versuche mit dem HBW Gerät hinter mir hatte zeigten meiner 12/7er keine Reaktion mehr. Im fhem Log lieferten sie Timeouts und ein Schalten über eingerichtete peerings auf dem selben 12/7er war auch erfolglos. Zu dem Zeitpunkt war das HBW Gerät nicht am Bus. Abhilfe schaffte ein Neustart des Bus und aller zugehörigen Geräte durch Stromentzug.

Was mir dabei noch aufgefallen ist sind freezes von fhem wenn ein Busteilnehmer nicht erreichbar ist. Da müsste ich aber wohl mit apptime mal nachsehen welche Stelle genau dafür verantwortlich ist. Wie da der HMLAN1 mit reinspielt geht an meinem Wissen jetzt allerdings völlig vorbei.

zwischen 20:30:28 und 20:32:19 wurde das HBW Gerät vom Bus getrennt.

2017.05.18 20:30:28 2: autocreate: define HBW_Sen_Key_12_HBW4073471 HM485 42FFFFFF HM485LAN
2017.05.18 20:30:28 2: autocreate: define FileLog_HBW_Sen_Key_12_HBW4073471 FileLog ./log/HBW_Sen_Key_12_HBW4073471-%Y.log HBW_Sen_Key_12_HBW4073471
2017.05.18 20:30:28 3: HBW_Sen_Key_12_HBW4073471: Request config for device 42FFFFFF
2017.05.18 20:30:28 3: HBW_Sen_Key_12_HBW4073471: Lese Eeprom 42FFFFFF
2017.05.18 20:32:19 3: HBW_Sen_Key_12_HBW4073471: RESPONSE TIMEOUT for 42FFFFFF
2017.05.18 20:32:30 1: 192.168.2.210:1000 disconnected, waiting to reappear (HMLAN1)
2017.05.18 20:32:30 1: HMLAN_Parse: HMLAN1 new condition disconnected
2017.05.18 20:32:30 1: Perfmon: possible freeze starting at 20:32:20, delay is 10.506
2017.05.18 20:32:30 3: HBW_Sen_Key_12_HBW4073471: Request config for device 42FFFFFF
2017.05.18 20:32:30 3: HBW_Sen_Key_12_HBW4073471: Lese Eeprom 42FFFFFF
2017.05.18 20:33:31 1: HMLAN_Parse: HMLAN1 new condition init
2017.05.18 20:33:31 1: 192.168.2.210:1000 reappeared (HMLAN1)
2017.05.18 20:33:31 1: HMLAN_Parse: HMLAN1 new condition ok


Grüße
Marcel

Thorsten Pferdekaemper

Zitat von: Lonie am 19 Mai 2017, 08:18:53ja, der war irgendwie da und in den HBW Tutorial ist er auch erwähnt. Deswegen ging ich davon aus dass man hier Hand anlegen muss.
Ich habe das jetzt aus dem Tutorial rausgeworfen. Außerdem siehe den github-Link in meinem Post vorher.
...den Rest schaue ich mir später mal an.
Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

Zitat von: Lonie am 19 Mai 2017, 08:18:53
Was mir dabei noch aufgefallen ist sind freezes von fhem wenn ein Busteilnehmer nicht erreichbar ist.
Das ist jetzt korrigiert. Bitte mal update machen.
Gruß,
   Thorsten
FUIP

Lonie

Dank dir für die flotte Behebung. fhem ist jetzt auch noch bedienbar wenn ein Busteilnehmer nicht gefunden wird.

Ich möchte auch nochmal sagen dass du ne Mega geniale Arbeit geleistet hast. Mit etwas Geschick und kleinem Portmonnaie bekommt man stabile Komponenten die den original HMW Produkten in fast nichts nachstehen.

Thorsten Pferdekaemper

Zitat von: Lonie am 19 Mai 2017, 22:41:00
Ich möchte auch nochmal sagen dass du ne Mega geniale Arbeit geleistet hast. Mit etwas Geschick und kleinem Portmonnaie bekommt man stabile Komponenten die den original HMW Produkten in fast nichts nachstehen.
Danke!
FUIP

Thorsten Pferdekaemper

Hi,
hier waren noch ein paar Sachen offen...

Zitat von: Lonie am 19 Mai 2017, 08:18:53
Ich bin mir nicht ganz sicher was der Grund war und kann nur die Auswirkungen beschreiben. Nachdem ich ja etliche erfolglose Versuche mit dem HBW Gerät hinter mir hatte zeigten meiner 12/7er keine Reaktion mehr. Im fhem Log lieferten sie Timeouts und ein Schalten über eingerichtete peerings auf dem selben 12/7er war auch erfolglos. Zu dem Zeitpunkt war das HBW Gerät nicht am Bus. Abhilfe schaffte ein Neustart des Bus und aller zugehörigen Geräte durch Stromentzug.
Das ist wirklich etwas seltsam, vor Allem wenn sogar interne Peerings nicht mehr gehen. Die sind nämlich, wenn sie mal eingerichtet sind, von FHEM unabhängig. Ich kann mir höchstens vorstellen, dass aus irgendeinem Grund (fehlender "Abschlusswiederstand"?) auf dem Bus viel los war und das die Geräte verwirrt hat. Aber so lange das nicht mehr auftritt werden wir es wohl nicht erfahren.

ZitatWie da der HMLAN1 mit reinspielt geht an meinem Wissen jetzt allerdings völlig vorbei.
Der HMLAN (also der von eq3) braucht alle 30 Sekunden oder so ein "Keepalive"-Signal. Wenn er das nicht bekommt, dann trennt er die Verbindung. Ich glaube, FHEM (also das HMLAN-Modul) sendet das Signal alle 20 Sekunden. Wenn jetzt irgendwas blockiert, dann kann es passieren, dass der HMLAN nicht mehr "drankommt" bevor der HMLAN (also das physikalisch Gerät) von sich aus die Verbindung trennt. Ab einer "Blockierung" von 10 Sekunden kann das passieren, ab 30 Sekunden passiert es zwangsläufig.
...so zumindest meine Theorie.

Gruß,
   Thorsten
FUIP