Homematic Wired - Homebrew Devices

Begonnen von Thorsten Pferdekaemper, 27 April 2014, 00:13:17

Vorheriges Thema - Nächstes Thema

Ralf9

Hast Du ein fhem restart gemacht, damit der HM485d neu gestartet wird?
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

loetmeister

Zitat von: aperoap am 10 August 2019, 23:48:30
Ich werde das mal ausprobieren, vielen Dank.

Hi,

hattest du die erweiterte Version, mit dem Sendepuffer mal ausprobiert? In meinen Tests hatte es funktioniert...

Hatte den Code noch etwas angepasst, um alle Nachrichten typen speichern zu können. D.h. im Prinzip wird die komplette Nachricht gespeichert, aber nur wenn die daten maximal 8 byte nicht überschreiten.

Ich muss das mal etwas ausgiebiger mit meinen Geräten testen...

static const uint8_t SEND_BUFFER_SIZE = 4; // amount of messages to store
static const uint8_t MAX_TX_BUFFER_FRAME_LENGTH = 8; // max frame size for the buffer

struct s_SendBuffer
{
uint32_t targetAddress;
uint8_t frameControlByte;
uint8_t frameDataLength;              // Laenge der Daten
uint8_t frameData[MAX_TX_BUFFER_FRAME_LENGTH]; // don't buffer large frames; frameDataLength < MAX_TX_BUFFER_FRAME_LENGTH
uint8_t reSendCounter;
};


Gruß,
Thomas

Thorsten Pferdekaemper

Zitat von: aperoap am 22 August 2019, 21:47:57
Hi habe HM485d_logVerbose auf 5 gestellt, ein logfile definiert und HM485d_logfile eingestellt. Die logs werden jedoch noch in fhem logfile geschriebem und nicht in HM485d_logfile. Mache ich was falsch?
Hi,
die Syntax mit %Y etc. funktioniert hier wahrscheinlich nicht. Das ist kein FHEM-FileLog, sondern einfach eine normale Betriebssystemdatei. Lass das mit dem speziellen Logfile am besten, dann sollte alles im normalen FHEM-Log landen.
Gruß,
   Thorsten
FUIP

aperoap

Zitat von: loetmeister am 24 August 2019, 00:03:18
Hi,

hattest du die erweiterte Version, mit dem Sendepuffer mal ausprobiert? In meinen Tests hatte es funktioniert...

Hatte den Code noch etwas angepasst, um alle Nachrichten typen speichern zu können. D.h. im Prinzip wird die komplette Nachricht gespeichert, aber nur wenn die daten maximal 8 byte nicht überschreiten.

Ich muss das mal etwas ausgiebiger mit meinen Geräten testen...

static const uint8_t SEND_BUFFER_SIZE = 4; // amount of messages to store
static const uint8_t MAX_TX_BUFFER_FRAME_LENGTH = 8; // max frame size for the buffer

struct s_SendBuffer
{
uint32_t targetAddress;
uint8_t frameControlByte;
uint8_t frameDataLength;              // Laenge der Daten
uint8_t frameData[MAX_TX_BUFFER_FRAME_LENGTH]; // don't buffer large frames; frameDataLength < MAX_TX_BUFFER_FRAME_LENGTH
uint8_t reSendCounter;
};


Gruß,
Thomas
habe es nicht ausprobiert, werde ich demnächst machen. Die Idee finde ich super.

Zitat von: Thorsten Pferdekaemper am 24 August 2019, 21:00:37
Hi,
die Syntax mit %Y etc. funktioniert hier wahrscheinlich nicht. Das ist kein FHEM-FileLog, sondern einfach eine normale Betriebssystemdatei. Lass das mit dem speziellen Logfile am besten, dann sollte alles im normalen FHEM-Log landen.
Gruß,
   Thorsten
super vielen Dank, lag wirklich an Syntax.  ;D ;)

Gruß

loetmeister

#589
Hallo,

habe die Änderungen für den Sendepuffer mal in GitHub geladen.
Um weniger Code zu belegen, habe ich die einzelnen Variablen zum senden eines Frames in einen struct (s_txFrame) übernommen, dann kann ich zwischen Puffer und dem aktuellen txFrame hin und her kopieren.

Das Verhalten für KeyEvent Nachrichten ist wie folgt:

  • Broadcast Nachrichten werden aktuell nicht gepuffert
  • Die Nachricht wird versucht, wie bisher, mit OnlyIfIdle zu senden - 1 Versuch!
  • Ist der Bus belegt, wird die Nachricht mit 3 möglichen Sendeversuchen in den Puffer übernommen
  • Es wird versucht zu senden, wenn der Bus frei ist, falls nicht wird alle 330 ms der Zähler reduziert (reSendCounter)
  • Der Puffer wird sequenziell abgearbeitet. Wenn ein Platz vor dem aktuell frei wird, kann er neu belegt werden, gesendet wird dieser aber erst wenn die weiteren aufsteigenden Plätze (sofern belegt) abgearbeitet wurden - d.h. gesendet order gelöscht
Edit : habe der Funktion sendKeyEvent den "enqueue" Parameter hinzugefügt. So lässt sich das Puffern aus dem Kanal steuern und unterdrücken, wenn es nicht sinnvoll ist. Das ganz setup müsste man noch ausgiebig testen... Also wer Lust hat, immer los.  8)
Was noch nicht gut ist: Wiederholte long press füllen den Puffer. Am einfachsten könnte ich einen Parameter  sendKeyEvent hinzufügen, dann lässt sich das direkt aus dem Kanal steuern...

https://github.com/loetmeister/HBWired/commit/ed0e3a02acfa4a9186ca7c7c0d354b632450cd87#diff-340d6f8cfa01a00fa61bea3db56dfddfR719

Zum testen, am besten den ganzen "lib" Ordner aktualisieren:
https://github.com/loetmeister/HBWired/tree/master/libraries/src

Gruß,
Thomas

holzwurm83

Hallo Thomas,

ich wollte heute einmal deinen HBW-SC-10-Dim-6 auf den nano spielen und ausprobieren. Aktuell wird er von Fhem nicht erkannt. Das liegt wohl auch an der pm Datei da diese aus der xml nicht generiert wird. Die Rechte habe ich mir schon einmal angeschaut und überprüft.

Hast du noch eine Idee!


Hier noch der Bus aus Fhem
Zitat2019.09.29 12:42:24.629 0: HM485d: Server stopped ...
2019.09.29 12:42:41.895 3: HM485d: port 2000 opened
2019.09.29 12:42:41.895 3: HM485d: server waiting for client connection on port 2000
2019.09.29 12:42:41.897 3: Opening SERIAL device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6025BA0-if00-port0
2019.09.29 12:42:41.952 3: SERIAL device opened
2019.09.29 12:42:41.955 3: HM485d: SERIALbaudrate=19200, databits=8, parity=even, stopbits=1, handshake=none
2019.09.29 12:42:41.955 2: HM485d: SERIAL connected to device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6025BA0-if00-port0
2019.09.29 12:42:41.956 1: HM485d: Server started ...
2019.09.29 12:42:46.550 4: Connection accepted from HM485d_127.0.0.1_42308
2019.09.29 12:42:46.557 4: HM485d: Tx: H00,01,HMW-SOFT-GW,0.2.2,SGW0123456

2019.09.29 12:42:46.565 4: HM485d: Rx: FD3E30312C303030300D0A
2019.09.29 12:43:06.573 4: HM485d: Rx: FD02024B
2019.09.29 12:43:06.574 4: HM485d: Tx: FD03026100
2019.09.29 12:43:26.577 4: HM485d: Rx: FD02034B
2019.09.29 12:43:26.578 4: HM485d: Tx: FD03036100
2019.09.29 12:43:46.586 4: HM485d: Rx: FD02044B
2019.09.29 12:43:46.587 4: HM485d: Tx: FD03046100
2019.09.29 12:44:06.595 4: HM485d: Rx: FD02054B
2019.09.29 12:44:06.596 4: HM485d: Tx: FD03056100
2019.09.29 12:44:26.602 4: HM485d: Rx: FD02064B
2019.09.29 12:44:26.602 4: HM485d: Tx: FD03066100
2019.09.29 12:44:46.612 4: HM485d: Rx: FD02074B
2019.09.29 12:44:46.613 4: HM485d: Tx: FD03076100
2019.09.29 12:45:06.623 4: HM485d: Rx: FD02084B
2019.09.29 12:45:06.624 4: HM485d: Tx: FD03086100
2019.09.29 12:45:26.630 4: HM485d: Rx: FD02094B
2019.09.29 12:45:26.630 4: HM485d: Tx: FD03096100
2019.09.29 12:45:46.641 4: HM485d: Rx: FD020A4B
2019.09.29 12:45:46.641 4: HM485d: Tx: FD030A6100
2019.09.29 12:46:06.652 4: HM485d: Rx: FD020B4B
2019.09.29 12:46:06.652 4: HM485d: Tx: FD030B6100
2019.09.29 12:46:26.659 4: HM485d: Rx: FD020C4B
2019.09.29 12:46:26.660 4: HM485d: Tx: FD030C6100
2019.09.29 12:46:46.670 4: HM485d: Rx: FD020D4B
2019.09.29 12:46:46.671 4: HM485d: Tx: FD030D6100

Und hier noch der SerialMonitor vom Device:
Zitat2019.09.29 12:42:24.629 0: HM485d: Server stopped ...
2019.09.29 12:42:41.895 3: HM485d: port 2000 opened
2019.09.29 12:42:41.895 3: HM485d: server waiting for client connection on port 2000
2019.09.29 12:42:41.897 3: Opening SERIAL device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6025BA0-if00-port0
2019.09.29 12:42:41.952 3: SERIAL device opened
2019.09.29 12:42:41.955 3: HM485d: SERIALbaudrate=19200, databits=8, parity=even, stopbits=1, handshake=none
2019.09.29 12:42:41.955 2: HM485d: SERIAL connected to device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6025BA0-if00-port0
2019.09.29 12:42:41.956 1: HM485d: Server started ...
2019.09.29 12:42:46.550 4: Connection accepted from HM485d_127.0.0.1_42308
2019.09.29 12:42:46.557 4: HM485d: Tx: H00,01,HMW-SOFT-GW,0.2.2,SGW0123456

2019.09.29 12:42:46.565 4: HM485d: Rx: FD3E30312C303030300D0A
2019.09.29 12:43:06.573 4: HM485d: Rx: FD02024B
2019.09.29 12:43:06.574 4: HM485d: Tx: FD03026100
2019.09.29 12:43:26.577 4: HM485d: Rx: FD02034B
2019.09.29 12:43:26.578 4: HM485d: Tx: FD03036100
2019.09.29 12:43:46.586 4: HM485d: Rx: FD02044B
2019.09.29 12:43:46.587 4: HM485d: Tx: FD03046100
2019.09.29 12:44:06.595 4: HM485d: Rx: FD02054B
2019.09.29 12:44:06.596 4: HM485d: Tx: FD03056100
2019.09.29 12:44:26.602 4: HM485d: Rx: FD02064B
2019.09.29 12:44:26.602 4: HM485d: Tx: FD03066100
2019.09.29 12:44:46.612 4: HM485d: Rx: FD02074B
2019.09.29 12:44:46.613 4: HM485d: Tx: FD03076100
2019.09.29 12:45:06.623 4: HM485d: Rx: FD02084B
2019.09.29 12:45:06.624 4: HM485d: Tx: FD03086100
2019.09.29 12:45:26.630 4: HM485d: Rx: FD02094B
2019.09.29 12:45:26.630 4: HM485d: Tx: FD03096100
2019.09.29 12:45:46.641 4: HM485d: Rx: FD020A4B
2019.09.29 12:45:46.641 4: HM485d: Tx: FD030A6100
2019.09.29 12:46:06.652 4: HM485d: Rx: FD020B4B
2019.09.29 12:46:06.652 4: HM485d: Tx: FD030B6100
2019.09.29 12:46:26.659 4: HM485d: Rx: FD020C4B
2019.09.29 12:46:26.660 4: HM485d: Tx: FD030C6100
2019.09.29 12:46:46.670 4: HM485d: Rx: FD020D4B
2019.09.29 12:46:46.671 4: HM485d: Tx: FD030D6100
- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

loetmeister

Hi,

Steht im fhem log etwas dazu? Bei jedem Start wird überprüft ob sich die xml Dateien geändert haben und eine neue pm Datei generiert. Ich wüsste jetzt nicht warum die xml bei dir nicht konvertiert wird.
Ohne passende pm sollte aber ein generic device angelegt werden....

Du hast, glaube ich auch versehentlich zweimal das selbe log in deinen Beitrag kopiert..

Gruß,
Thomas

holzwurm83

Das war in der tat der Falsche...
Hier der SerialMonitor vom Device:
B: 2A 367
VKey_ch:0 short
T: FD:FF:FF:FF:FB: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367
se⸮B: 2A 367


Und hier der Fhem Log:
Zitat019.09.29 17:24:03 3: Probing FRM device /dev/ttyUSB0
2019.09.29 17:24:08 1: usb create end
2019.09.29 17:24:08 0: Featurelevel: 5.9
2019.09.29 17:24:08 0: Server started with 11 defined entities (fhem.pl:20069/2019-08-27 perl:5.028001 os:linux user:fhem pid:635)
2019.09.29 17:24:08 3: hm485: Start HM485d with command line: ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000001 --serialNumber SGW0123456 --device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6025BA0-if00-port0 --localPort 2000 --logfile ./log/HM485-2019-37.log --verbose 4
2019.09.29 17:24:08 3: hm485: HM485d was started with PID:   645
2019.09.29 17:24:08 3: hm485: Connect to HM485d delayed for 5 seconds
2019.09.29 17:24:13 3: Opening hm485 device localhost:2000
2019.09.29 17:24:13 3: hm485: connected to device localhost:2000
2019.09.29 17:24:13 3: hm485 device opened
2019.09.29 17:24:13 3: hm485: Lan Device Information
2019.09.29 17:24:13 3: hm485: Protocol-Version: 01
2019.09.29 17:24:13 3: hm485: Interface-Type: HMW-SOFT-GW
2019.09.29 17:24:13 3: hm485: Firmware-Version: 0.2.2
2019.09.29 17:24:13 3: hm485: Serial-Number: SGW0123456
2019.09.29 17:24:13 5: hm485: HM485_LAN_Write TX: 1
2019.09.29 17:24:13 3: hm485: Initialize the interface
2019.09.29 17:24:13 5: SW: fd3e30312c303030300d0a
2019.09.29 17:24:17 2: AttrTemplates: got 102 entries
- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

loetmeister

Zitat von: holzwurm83 am 29 September 2019, 17:25:20
Das war in der tat der Falsche...
Hier der SerialMonitor vom Device:
B: 2A 367
VKey_..


Hi,

Da stimmt was nicht. Der Arduino scheint in einer Schleife zu hängen...  "B: 2A " darf nur einmal beim Start des devices angezeigt werden.
Gab es Warnungen beim kompilieren?
Kannst du zur Sicherheit noch mal die aktuelle library runter laden?


Gruß,
Thomas

holzwurm83

Zitat von: loetmeister am 30 September 2019, 00:18:01
Gab es Warnungen beim kompilieren?
Kannst du zur Sicherheit noch mal die aktuelle library runter laden?


Ja, dass die OneWire.h fehlt. Danach habe ich die HBWOneWireTempSensors aus dem lib Ordner gelöscht. Danach gab es keine Fehler mehr.

Habe gerade auch nochmal den ganzen Ordner hier geladen:

https://github.com/loetmeister/HBWired

Der Serialmonitor zeigt weiterhin das gleiche an.

Hast du noch eine andere Idee?
- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

loetmeister

#595
Hi,

Nicht so richtig...  Du kompilierst die exakte Version die im github liegt?
Ich hatte mal arge Probleme mit den Arduino Versionen ab 1.8.6. Die funktionierte nur, wenn ich auf die alten kompiler Version zurück gegangen bin (EDIT: Arduino IDE 1.8.9 + AVR Boards, Version 1.6.21).
welche Version nutzt du? In der aktuellen 1.8.10 Version soll das Problem behoben sein.

Gruß,
Thomas

holzwurm83

Ja, ich habe mir die wie oben im Link runter geladen. Ich habe auch die Arduino 1.8.9 Version.
- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

holzwurm83

Hallo Thomas,

habe es gerade mal auf einen anderen Nano gespielt und da sieht es im Serialmonitor schon mal gut aus.

LH⸮)⸮B: 2A 367
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 367
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 367
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C
B: 2A 367
T: FD:FF:FF:FF:FF:F8:42:00:00:18:12:41:00:96:01:00:05:48:42:57:37:32:39:36:32:38:30:8B:2C


Kann es gerade nur in meinem Testsystem nicht testen.
- Fhem auf einem MacMini Server
- CUL; HMLAN; CUNO2 für FS20; HM-Wired RS485 LAN Gateway
- HMW_Sen_SC_12_FM; HMW_LC_Sw2_DR; HMW_LC_Bl1_DR; HMW_IO_12_Sw7; HMW_IO_12_Sw14_DR; HMW_IO_12_FM; HBW_1W_T10
- HM-TC-IT-WM-W-EU; HM-CC-RT-DN

Thorsten Pferdekaemper

Hi,
sieht das wirklich gut aus? Ich denke mal, dass die A-Message eigentlich nur einmal beim Einschalten rausgehen sollte.
Gruß,
   Thorsten
FUIP

loetmeister

#599
Hi,

ich vermute mal es ist ein ähnliches Problem, welches ich auch hatte (https://forum.fhem.de/index.php/topic,22952.msg876113.html#msg876113) und den Arduino in eine reboot Schleife bringt.
Seitdem hatte ich zwar neue Versionen der Arduino IDE genutzt, aber die alte Version (1.6.21) der Arduino AVR Boards. (habe mein vorherigen Post dahingehen korrigiert.

Ich habe mal einen kurzen Test mit der aktuellen IDE 1.8.10 und Arduino AVR Boards, Version 1.8.1 gemacht (die aktuelle Version, die bei der IDE dabei ist).
HBW-SC-10-Dim-6 meldet sich im Serial Monitor korrekt mit einer "B: 2A ..." Meldung und Announce Nachricht.

EDIT: Leider ist das Problem nicht ganz behoben.. es fehlen Teile des Codes... das Gerät funktioniert nicht richtig! Es ist noch immer Version (1.6.21) der Arduino AVR Boards nötig... (umstellen, unter "tools > board:... > boards manager...")

Gruß,
Thomas