EibPC reagiert extrem langsam (im normalen Betrieb)

[Reason555]

Guten Abend zusammen,

seit gestern habe ich folgendes Problem: der EibPC reagiert sehr langsam auf Bus-Telegramme. Das stört mich eigentlich nicht so sehr, allerdings gibt es eine Anwendung wo das wirklich inakzeptabel ist. Und zwar dimme ich bestimmte Leuchten ab einer gewissen Uhrzeit. Wenn ich dann beispielsweise ins Bad gehe sendet der BWM ein Ein-Signal an den Dimmer und der EinbPC schickt direkt ein Dimmwert=30% hinterher. Allerdings dauert dieses hinterherschicken teilweise bis zu 5 Sekunden.

Ich habe gestern lediglich eine Sache geändert die anscheinend zu dem Problem geführt haben, ich nutze 1-Wire Sensoren am HA7E Adapter, bislang waren 4 Sensoren angeschlossen, seit gestern sind es 8. Seit dem besteht das Problem, Auslastung des EibPC liegt bei 26%, sollte daher eigentlich kein Thema sein. Ich nutze übrigens das BMX22 Makro für den HA7E.

Hat einer von Euch eine Idee was ich hier machen kann? Mir würde es reichen, wenn ich den Dimmer Befehl irgendwie priorisieren könnte, der Rest ist zeitlich nicht kritisch. Oder gibt es bei den 1-Wire Makros einen Ansatz zur Optimierung? Ich nutze natürlich die neusten Releases für den EibPC.

Beste Grüße
Nils

[Jambala]

Hallo Nils,

hast Du diese Verhalten auch nach einem Neustart?

Wenn Du beim 1-Wire Makro das Debbuging aktiviert hast, könnte dies z.B. eine Ursache sein,
da der EibPC damit sehr beschäftigt wird.

Viele Grüße

Michael

[Reason555]

Hallo Michael,

das Problem ist auch nach einem Neustart vorhanden. Debugging ist vermutlich aus, da ich überhaupt nicht weiß wie ich es einschalten kann. Ich nehme ja nicht an dass es per Default an ist, oder? Wie kann ich es denn ausschalten, nur um ganz sicher zu gehen?

Beste Grüße
Nils

[Jambala]

Hallo Nils,

das UDP Debugging aktivierst Du über den Makro Aufruf:

HA7E_Init(HA7E_Debug_None, 5050u16, 192.168.0.2, '9/6/0'b01, '9/6/2'b01 )

Hinter der Klammer muß "HA7E_Debug_None" stehen.

Im Makro findest Du Erklärungen zu den einzelnen Debugging Modi:

HA7E_Debug_None = 0u08; /* no debug infos at all */
HA7E_Debug_Result = 1u08; /* e.g. conversion results of a sensor */
HA7E_Debug_Error = 2u08; /* all error messages, e.g. conversion failed, sensor not found */
HA7E_Debug_Command = 4u08; /* all command related messages */
HA7E_Debug_Queue = 8u08; /* all queue changes */
HA7E_Debug_Init = 16u08; /* init commands */
HA7E_Debug_Read = 32u08; /* read commands */
HA7E_Debug_Write = 64u08; /* write commands */
HA7E_Debug_Device = 128u08; /* device selection */

Viele Grüße

Michael

[Reason555]

Besten Dank Michael,

werde ich direkt ausprobieren heute Abend. Bei mir stand "HA7E_Debug_Verbose", was auch immer das dann war.
Ich werde berichten.

Beste Grüße
Nils

[Jambala]

HA7E_Debug_Verbose = 255u08; /* every error is displayed */

[Reason555]

Hört sich nach viel Last an, dann sollte es ja jetzt gehen :-)

[Jambala]

denke ich auch...

[bmx]

Am besten wäre es, wenn Du die Definition für HA7E_DebugOut_String komplett rauswirfst, sonst bleiben die ganzen if trotzdem drin.

Du kannst die Definition für HA7E_DebugOut_String im Makro

:begin HA7E_DebugOut_String( DebugLevel, OutMessage )
:info $Send a text string to a UDP receiver$
:shortinfo $Send debug messages via UDP$
:var HA7EStr@
HA7EStr@ = $$
:return if (HA7E_Debug_Level and DebugLevel) > 0u08 then HA7EStr@ = OutMessage; sendudp(HA7E_Debug_Port,HA7E_Debug_IP, $@ $+Debug_Currenttime+$, HA7E:$, HA7EStr@, 13, 10 ) endif
:end

auch ersetzen durch

:begin HA7E_DebugOut_String( DebugLevel, OutMessage )
:info $Send a text string to a UDP receiver$
:shortinfo $Send debug messages via UDP$
:var HA7EStr@
HA7EStr@ = $$
:return sun()
:end

Sehr clever kannst Du das ganze natürlich kapseln if #define und #ifdef.

Gruß,
Bernd

[enertegus]

Sehr clever kannst Du das ganze natürlich kapseln if #define und #ifdef.

Genau, die Sache mit sun() ist auch nur ein Hack.

[Reason555]

Hallo zusammen,

ich wollte ja nochmal über das Ergebnis berichten, Performance ist jetzt wieder einwandfrei. Ich habe gestern aber durch Zufall noch einen Effekt erkannt:
Wenn gerade die Wetterabfrage über das Wunderground Makro läuft habe ich diese Verzögerungen beim Dimmwert-senden auch. Damit ist aber ja umzugehen, kann man ja auch eine "Lastarme" Zeit legen.

Gruß und Danke nochmals
Nils

[EPIX]

Sehr clever kannst Du das ganze natürlich kapseln if #define und #ifdef.

aber die Einbindung passiert doch während des Compilierungsvorganges - zur Laufzeit kann man dann den Debug nicht mehr aktivieren? - oder lieg' ich da falsch

[bmx]

@Epix: Korrekt. Im Normalfall muß man ja auch nicht immer debuggen. Und es klaut dem EibPC schon Performance, wenn er wegen jedem bischen vom HA7E Makro ein UDP Paket schnüren und schicken muß...

[EPIX]

OK, ging mir nur ums Prinzip - ich nutz' die #ifdefine eben auch für den Zweck für gaaaaanz selteen Fälle
oder eben die Variable mit if debugFreigabe then blabla für das fallsweise debuggen...
Nachdem die debugFreigabe zu 99% auf AUS steht wird der performance Einbruch nicht so wild sein

Wenn gerade die Wetterabfrage über das Wunderground Makro läuft habe ich diese Verzögerungen beim Dimmwert-senden auch. Damit ist aber ja umzugehen, kann man ja auch eine "Lastarme" Zeit legen.

d.h. bei solchen umfangreichen Abfragen vorher mit processortime (o.ä.) die aktuelle Belastung testen?

[enertegus]

:
Wenn gerade die Wetterabfrage über das Wunderground Makro läuft habe ich diese Verzögerungen beim Dimmwert-senden auch. Damit ist aber ja umzugehen, kann man ja auch eine "Lastarme" Zeit legen

Welche Version des Makros nutzt du? Wir haben extra das Makro ressourcenschonend entschlackt. Sollte in der enertexV2.lib stehen