Autor Thema: Homematic Wired - Homebrew Devices  (Gelesen 139722 mal)

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2453
Antw:Homematic Wired - Homebrew Devices
« Antwort #585 am: 22 August 2019, 23:51:00 »
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
SIGNALduino promini (LAN cc1101 + WLAN RXB6), WH3080,  Hideki, Id 7

Offline loetmeister

  • Full Member
  • ***
  • Beiträge: 148
Antw:Homematic Wired - Homebrew Devices
« Antwort #586 am: 24 August 2019, 00:03:18 »
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

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5563
  • Finger weg von der fhem.cfg
Antw:Homematic Wired - Homebrew Devices
« Antwort #587 am: 24 August 2019, 21:00:37 »
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
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline aperoap

  • New Member
  • *
  • Beiträge: 38
Antw:Homematic Wired - Homebrew Devices
« Antwort #588 am: 25 August 2019, 12:39:46 »
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.

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ß

Offline loetmeister

  • Full Member
  • ***
  • Beiträge: 148
Antw:Homematic Wired - Homebrew Devices
« Antwort #589 am: 28 August 2019, 23:48:43 »
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
« Letzte Änderung: 31 August 2019, 13:02:38 von loetmeister »