HMinfo Protokoll - Versionsgeschichte

Drhirn: Und noch ein Formatierungsfehler

2018-06-13T14:16:26Z

Und noch ein Formatierungsfehler

← Nächstältere Version		Version vom 13. Juni 2018, 16:16 Uhr
Zeile 40:		Zeile 40:
	FHEM kennt alle Kommunikationstypen und behandelt diese entsprechend. Zu beachten ist, dass ein HM Gerät aus mehreren Entities besteht: Ein Device und ein oder mehrere Kanäle. Man kann mit den Kanälen nicht direkt kommunizieren. Die Kommunikation geht immer über das Device. So ist es in FHEM auch organisiert. Löst man ein Kommando für einen Kanal aus wir dies in die Abarbeitungsliste der Device gestellt. Je nach Kommunikationstyp arbeitet FHEM die Liste schnellstmöglich ab. <br>		FHEM kennt alle Kommunikationstypen und behandelt diese entsprechend. Zu beachten ist, dass ein HM Gerät aus mehreren Entities besteht: Ein Device und ein oder mehrere Kanäle. Man kann mit den Kanälen nicht direkt kommunizieren. Die Kommunikation geht immer über das Device. So ist es in FHEM auch organisiert. Löst man ein Kommando für einen Kanal aus wir dies in die Abarbeitungsliste der Device gestellt. Je nach Kommunikationstyp arbeitet FHEM die Liste schnellstmöglich ab. <br>
	Hierbei ist zu beachten, dass an die Devices über ein oder mehrere IOs gesendet wird. Auch hier wird wieder der Reihe nach vorgegangen, ein Device nach dem anderen. <br>		Hierbei ist zu beachten, dass an die Devices über ein oder mehrere IOs gesendet wird. Auch hier wird wieder der Reihe nach vorgegangen, ein Device nach dem anderen. <br>
	Wir haben also gelernt, dass Kommandos, welche FHEM senden will, in den Kommando-Queues der Devices abgelegt werden. Will nun sehen, ob schon alles erledigt ist, oder ob Fehler aufgetreten sind, muss man den Status der Kommando-queue lesen. Dieser wird in den '''Internals''' welche mit '''[[prot]]''' (Protokoll) beginnend ermittelt.		Wir haben also gelernt, dass Kommandos, welche FHEM senden will, in den Kommando-Queues der Devices abgelegt werden. Will nun sehen, ob schon alles erledigt ist, oder ob Fehler aufgetreten sind, muss man den Status der Kommando-queue lesen. Dieser wird in den '''Internals''' welche mit '''''prot''''' (Protokoll) beginnend ermittelt.
	*'''protState''':Der gesamt-Zustand der Queue.		*'''protState''':Der gesamt-Zustand der Queue.
	**'''''CMDs_done''''': Alle Kommandos übertragen, es sind bei ''der letzten'' Übertragung keine Fehler aufgetreten		**'''''CMDs_done''''': Alle Kommandos übertragen, es sind bei ''der letzten'' Übertragung keine Fehler aufgetreten

Drhirn: Formatierungsfehler korrigiert

2018-06-13T14:09:40Z

Formatierungsfehler korrigiert

Drhirn: Formatierungsfehler korrigiert

2018-06-13T13:07:53Z

Formatierungsfehler korrigiert

Ph1959de: Infobox-Verwendung korrigiert

2018-02-20T14:53:44Z

Infobox-Verwendung korrigiert

← Nächstältere Version		Version vom 20. Februar 2018, 16:53 Uhr
Zeile 5:		Zeile 5:
	\|ModForumArea=HomeMatic		\|ModForumArea=HomeMatic
	\|ModTechName=98_HMinfo.pm		\|ModTechName=98_HMinfo.pm
	\|ModOwner=martinp876 ({{Link2FU\|251\|martinp876}} / [[Benutzer Diskussion:Martinp876\|Wiki]])		\|ModOwner=martinp876 ({{Link2FU\|251\|martinp876}}/[[Benutzer Diskussion:Martinp876\|Wiki]])
	}}		}}

Krikan: Gliederungsebenen angepasst; tote intrawiki-Links durch kursiv-Schreibung ersetzt

2018-02-20T14:49:02Z

Gliederungsebenen angepasst; tote intrawiki-Links durch kursiv-Schreibung ersetzt

Änderungen zeigen

Krikan: Krikan verschob die Seite Himfo Protokol nach HMinfo Protokoll, ohne dabei eine Weiterleitung anzulegen: Tippfehler in Seitentitel

2018-01-28T17:38:46Z

Krikan verschob die Seite Himfo Protokol nach HMinfo Protokoll, ohne dabei eine Weiterleitung anzulegen: Tippfehler in Seitentitel

← Nächstältere Version		Version vom 28. Januar 2018, 19:38 Uhr
(kein Unterschied)

Martinp876 am 4. Januar 2018 um 20:13 Uhr

2018-01-04T20:13:25Z

← Nächstältere Version		Version vom 4. Januar 2018, 22:13 Uhr
Zeile 65:		Zeile 65:
	Die Kommunikation setzt ein straffes Timing der Nachrichtenübermittlung voraus. Eine Nachricht muss in einem Zeitfenster von 100ms-250ms nach senden beantwortet werden. Aufgrund der Natur von FHEM mit IOs welche über unzureichende Betriebssysteme angeschlossen werden kann das Timing nur schwer gewährleistet werden. Verzogerungen durch LAN oder USB müssen berechnet werden		Die Kommunikation setzt ein straffes Timing der Nachrichtenübermittlung voraus. Eine Nachricht muss in einem Zeitfenster von 100ms-250ms nach senden beantwortet werden. Aufgrund der Natur von FHEM mit IOs welche über unzureichende Betriebssysteme angeschlossen werden kann das Timing nur schwer gewährleistet werden. Verzogerungen durch LAN oder USB müssen berechnet werden
	*HM-IOs: IO Devices von eq3 stellen eine Zeitstempel bereit welcher zur Kalkulation der Verzögerung genutzt werden kann. Das funktioniert in der Regel problemlos		*HM-IOs: IO Devices von eq3 stellen eine Zeitstempel bereit welcher zur Kalkulation der Verzögerung genutzt werden kann. Das funktioniert in der Regel problemlos
	*CUL: Da die CUL keinen Zeitstempel zu ~~verfügung~~ stellt ist sie für HM Kommunikation nicht zu brauchen. Siehe TSCUL		*CUL: Da die CUL keinen Zeitstempel zu Verfügung stellt ist sie für HM Kommunikation nicht zu brauchen. Siehe TSCUL
	*TSCUL: Durch einen FW Update kann eine CUL einen Zeitstempel generieren und schicken welcher diese dann		*TSCUL: Durch einen FW Update kann eine CUL einen Zeitstempel generieren und schicken welcher diese dann
	einem HM-IO gleichwertig macht.		einem HM-IO gleichwertig macht.

Martinp876 am 4. Januar 2018 um 20:12 Uhr

2018-01-04T20:12:40Z

← Nächstältere Version		Version vom 4. Januar 2018, 22:12 Uhr
Zeile 62:		Zeile 62:
	set hm clearG msgErrors # löscht alle Zähler der Devices welche Fehler anzeigen.		set hm clearG msgErrors # löscht alle Zähler der Devices welche Fehler anzeigen.
	Ein Löschen ist gelegentlich sinnvoll, da Fehler kontinuierlch akkumuliert werden. Wenn man die Fehler nun erfasst hat kann man diese zurücksetzen um neu auftretende besser zu erkennen.		Ein Löschen ist gelegentlich sinnvoll, da Fehler kontinuierlch akkumuliert werden. Wenn man die Fehler nun erfasst hat kann man diese zurücksetzen um neu auftretende besser zu erkennen.
			==Kommunikation Timing==
			Die Kommunikation setzt ein straffes Timing der Nachrichtenübermittlung voraus. Eine Nachricht muss in einem Zeitfenster von 100ms-250ms nach senden beantwortet werden. Aufgrund der Natur von FHEM mit IOs welche über unzureichende Betriebssysteme angeschlossen werden kann das Timing nur schwer gewährleistet werden. Verzogerungen durch LAN oder USB müssen berechnet werden
			*HM-IOs: IO Devices von eq3 stellen eine Zeitstempel bereit welcher zur Kalkulation der Verzögerung genutzt werden kann. Das funktioniert in der Regel problemlos
			*CUL: Da die CUL keinen Zeitstempel zu verfügung stellt ist sie für HM Kommunikation nicht zu brauchen. Siehe TSCUL
			*TSCUL: Durch einen FW Update kann eine CUL einen Zeitstempel generieren und schicken welcher diese dann
			einem HM-IO gleichwertig macht.
			Das Timing kann aber auch durch Verzögerungen auf den Rechner, innerhalb oder ausserhalb von FHEM gestört werden, wenn langsame oder hochpriore Tasks den Ablauf stören. apptime kann genutzt werden um verzögerungen im System aufzudecken.
			pairen: ist eine besondere Herausforderung. Hier müssen ggf. erst entities in FHEM angelegt werden, bevor geantwortet werden kann. Es ist nicht sinnvoll nach einem ersten pairing Versuch alle Entites aus FHEM wieder zu löschen. Sollte das pairen nicht funktioniert haben kann man die Kommando Queue leeren (set hm clearG msgEvents) und dann einen neuen Versuch starten.

	[[Kategorie:HomeMatic supportDevice]]		[[Kategorie:HomeMatic supportDevice]]
	[[Kategorie:HOWTOS]]		[[Kategorie:HOWTOS]]

Martinp876 am 4. Januar 2018 um 19:58 Uhr

2018-01-04T19:58:58Z

← Nächstältere Version		Version vom 4. Januar 2018, 21:58 Uhr
Zeile 53:		Zeile 53:
	*'''protNack''': Anzahl der negativen Acknowledges, welche vom Devices empfangen wurden.		*'''protNack''': Anzahl der negativen Acknowledges, welche vom Devices empfangen wurden.
	*'''protIOerr''': Anzahl der Fehler, IO bedingt.		*'''protIOerr''': Anzahl der Fehler, IO bedingt.
			===HMinfo Support zu Protokoll Ereignissen===
			Da nun einiges kontinuierlich passiert und die Anzahl der Devices typisch steigt bedarf es eine Übersicht, den Zustand des Systems zu überwachen:
			get hm protoEvents
			zeigt eine Tabelle aller Devices, deren Zustand der Kommando-Queue und eine Statitik der Übertragungen. Nach dem '#' sollten keine Zähler stehen. Die dortigen bedeuten, dass einige Kommandos gelöscht wurden.
			Im Nachspann stehen Informationen über weitere Queues con CUL_HM. So bspw devices bei welchen FHEM die Register noch lesen will (autoReadReg) falls dies über ein entsprechendes Attribut eingestellt wurde. <br>
			Will man aufräumen kann man
			set hm clearG msgEvents # löscht alle Zähler und [[leert die Kommando-Queue]] '''aller''' Devices
			set hm clearG msgErrors # löscht alle Zähler der Devices welche Fehler anzeigen.
			Ein Löschen ist gelegentlich sinnvoll, da Fehler kontinuierlch akkumuliert werden. Wenn man die Fehler nun erfasst hat kann man diese zurücksetzen um neu auftretende besser zu erkennen.


	[[Kategorie:HomeMatic supportDevice]]		[[Kategorie:HomeMatic supportDevice]]
	[[Kategorie:HOWTOS]]		[[Kategorie:HOWTOS]]

Martinp876 am 4. Januar 2018 um 19:28 Uhr

2018-01-04T19:28:32Z

← Nächstältere Version		Version vom 4. Januar 2018, 21:28 Uhr
Zeile 41:		Zeile 41:
	Wir haben also gelernt, dass Kommandos, welche FHEM senden will, in den Kommando-Queues der Devices abgelegt werden. Will nun sehen, ob schon alles erledigt ist, oder ob Fehler aufgetreten sind, muss man den Status der Kommando-queue lesen. Dieser wird in den '''Internals''' welche mit '''[[prot]]''' (Protokol) beginnend ermittelt.		Wir haben also gelernt, dass Kommandos, welche FHEM senden will, in den Kommando-Queues der Devices abgelegt werden. Will nun sehen, ob schon alles erledigt ist, oder ob Fehler aufgetreten sind, muss man den Status der Kommando-queue lesen. Dieser wird in den '''Internals''' welche mit '''[[prot]]''' (Protokol) beginnend ermittelt.
	*'''protState''':Der gesamt-Zustand der Queue.		*'''protState''':Der gesamt-Zustand der Queue.
	**CMDs_done		**[[CMDs_done]]: Alle Kommandos übertragen, es sind bei [[der letzten]] Übertragung keine Fehler aufgetreten
			**[[CMDs_done_Errors:<no>]]: Alle Kommandos übertragen, es sind bei [[der letzten]] Fehler aufgetreten
			**[[CMDs_pending]]: Es stehen Kommandos zur Übertragung an. Es wird auf die Möglichkeit der Übertragung gewartet. Bspw. auf das Aufwachen eine wakeup Devices.
			**[[CMDs_processing...]]: Die Kommandos aus der Queue werden gerade abgearbeitet. Dies kann je nach Device und Menge auch etwas dauern.
			*'''protLastRcv''': Zeitpunkt der letzten empfangenen Nachricht dieses Device
			*'''protSnd''': Zählt die gesenderen Nachrichten und zeigt den letzten Sendezetpunkt an.
			*'''protCmdPend''': Anzahl der in der Kommando-Queue wartenden Nachrichten
			*'''protResnd''': Anzahl der (erfolgreich) wiederholten Nachrichten
			*'''protCmdDel''': Anzahl der auf Grund von Übertragungsproblemen gelöchten Nachrichten
			*'''protResndFail''': Anzahl der Wiederholungen welche nicht erfolgreich abgschlossen werden konnten
			*'''protNack''': Anzahl der negativen Acknowledges, welche vom Devices empfangen wurden.
			*'''protIOerr''': Anzahl der Fehler, IO bedingt.


	[[Kategorie:HomeMatic supportDevice]]		[[Kategorie:HomeMatic supportDevice]]
	[[Kategorie:HOWTOS]]		[[Kategorie:HOWTOS]]

← Nächstältere Version		Version vom 13. Juni 2018, 16:09 Uhr
Zeile 16:		Zeile 16:
	===Kommunikationstypen===		===Kommunikationstypen===
	Homematic bietet unterschiedliche Devices, teils batteriebetrieben. Die Energieversorgung ist der wesentliche Grund unterschiedliche Typen zu etablieren. Sollte ein batteriebetriebenes Device kontinuierlich auf Empfang sein senkt das die Lebensdauer der Batterie erheblich. Somit unterscheidet man		Homematic bietet unterschiedliche Devices, teils batteriebetrieben. Die Energieversorgung ist der wesentliche Grund unterschiedliche Typen zu etablieren. Sollte ein batteriebetriebenes Device kontinuierlich auf Empfang sein senkt das die Lebensdauer der Batterie erheblich. Somit unterscheidet man
	* '''[[Config]]''':Dieser Modus wird von ''allen'' Devices unterstützt. Hierbei wird das Device durch drücken einer Taste (typisch einer separaten, versteckten Taste) in den Mode versetzt. Die Taste wird gelegentlich auch Anlerntaste genannt. Das Device sendet hierbei eine Konfigmessage und bleibt einige Sekunden auf Empfang. Ein anderes Device hat nun die Chance mit dem Device zu kommunizieren.		* '''''Config''''': Dieser Modus wird von ''allen'' Devices unterstützt. Hierbei wird das Device durch drücken einer Taste (typisch einer separaten, versteckten Taste) in den Mode versetzt. Die Taste wird gelegentlich auch Anlerntaste genannt. Das Device sendet hierbei eine Konfigmessage und bleibt einige Sekunden auf Empfang. Ein anderes Device hat nun die Chance mit dem Device zu kommunizieren.
	:Dieser Mode wird gerne zum Pairen genutzt.		:Dieser Mode wird gerne zum Pairen genutzt.
	:Die FHEM Zentrale erkennt die Message und startet die Abarbeitung eventuell anhängiger Messages		:Die FHEM Zentrale erkennt die Message und startet die Abarbeitung eventuell anhängiger Messages
	* '''[[normal]]''':Typischerweise wird dieser Mode von allen Devices mit permanenter Stromversorgung unterstützt. Das Device ist kontinuierlich auf Empfang. Config wird von diesen Devices typisch nur zum pairen genutzt		* '''''normal''''': Typischerweise wird dieser Mode von allen Devices mit permanenter Stromversorgung unterstützt. Das Device ist kontinuierlich auf Empfang. Config wird von diesen Devices typisch nur zum pairen genutzt
	* '''[[wakeup]]''':Batteriebetriebene Devices welche regelmäßig senden stellen gerne diesen Modus bereit. Einige Devices welche regelmäßig senden (Thermostate oder Fühler) bleiben nach senden der zyklischen Nachricht kurz auf Empfang. FHEM erkennt dies und sendet gegebenenfalls anhängige Nachrichten und Abfragen.		* '''''wakeup''''': Batteriebetriebene Devices welche regelmäßig senden stellen gerne diesen Modus bereit. Einige Devices welche regelmäßig senden (Thermostate oder Fühler) bleiben nach senden der zyklischen Nachricht kurz auf Empfang. FHEM erkennt dies und sendet gegebenenfalls anhängige Nachrichten und Abfragen.
	* '''[[lazyConf]]''':Einige modernere Devices, batteriebetrieben und unregelmäßig sendend, stellen einen trägen Config mode bereit. Hierbei bleibt das Device auf Empfang, wenn dies einen Trigger gesendet hat.		* '''''lazyConf''''': Einige modernere Devices, batteriebetrieben und unregelmäßig sendend, stellen einen trägen Config mode bereit. Hierbei bleibt das Device auf Empfang, wenn dies einen Trigger gesendet hat.
	:Beispiel ist eine Fernbedienung welche nach drücken eines Buttons den Trigger sendet und dann kurz auf weitere Nachrichten wartet. Auch einige Bewegungsmelder unterstützen dies. Hier muss man also einen Trigger auslösen (Bewegung). Das Device reagiert nicht nach dem Senden der zyklischen Nachrichten.		:Beispiel ist eine Fernbedienung welche nach drücken eines Buttons den Trigger sendet und dann kurz auf weitere Nachrichten wartet. Auch einige Bewegungsmelder unterstützen dies. Hier muss man also einen Trigger auslösen (Bewegung). Das Device reagiert nicht nach dem Senden der zyklischen Nachrichten.
	:Erfahrungsgemäß funktioniert dies allerdings nur, wenn das Device den Trigger an die Zentrale sendet. Es ist also ratsam, alle Kanäle (jeden einzeln) mit einem Kanal der Zentrale zu peeren. Es biete sich an, einen virtuellen Button der Zentrale zu nutzen, welche man mit allen Kanälen aller LazyConfig Devices peert.		:Erfahrungsgemäß funktioniert dies allerdings nur, wenn das Device den Trigger an die Zentrale sendet. Es ist also ratsam, alle Kanäle (jeden einzeln) mit einem Kanal der Zentrale zu peeren. Es biete sich an, einen virtuellen Button der Zentrale zu nutzen, welche man mit allen Kanälen aller LazyConfig Devices peert.
	* '''[[burst]]''':Burst ist ein Verfahren, schlafende Devices aufzuwecken. Einige sind im Dämmerschlaf und können durch einen Burst aufgeweckt werden. Burst ist ein Kommandosequenz welche der Initiator senden muss. Diese ist aufwändig, verbraucht einiges an Funkperformance (1% Regel) und weckt ''alle'' Burst Devices gleichzeitig auf. Als Daumenregel kann ein Device in einer Stunde 100 Bursts senden bevor die 1% Regel zuschlägt.		* '''''burst''''': Burst ist ein Verfahren, schlafende Devices aufzuwecken. Einige sind im Dämmerschlaf und können durch einen Burst aufgeweckt werden. Burst ist ein Kommandosequenz welche der Initiator senden muss. Diese ist aufwändig, verbraucht einiges an Funkperformance (1% Regel) und weckt ''alle'' Burst Devices gleichzeitig auf. Als Daumenregel kann ein Device in einer Stunde 100 Bursts senden bevor die 1% Regel zuschlägt.
	:SD (Rauchdetektoren) verwenden typisch burst. Sie müssen empfangsbereit sein, laufen mit Batterie und müssen demnach Sparsam sein.		:SD (Rauchdetektoren) verwenden typisch burst. Sie müssen empfangsbereit sein, laufen mit Batterie und müssen demnach Sparsam sein.
	* '''[[burstCond]]''':ist eine Variante des Burst. Der Burstmode kann bei ihnen freigeschaltet werden. Beispielsweise RT (Heizungsthermostate) nutzen diesen Mode. Ein RT sendet regelmäßig seinen Status - und hierbei kann man über wakeup mit dem Device alle 3min kommunizieren. Nun muss ein RT aber auf Fensterkontakte reagieren können. Diese senden Asynchron. Man muss also sicherstellen, dass der Fensterkontakt einen Burst sendet und der RT auf Burst reagiert.		* '''''burstCond''''': ist eine Variante des Burst. Der Burstmode kann bei ihnen freigeschaltet werden. Beispielsweise RT (Heizungsthermostate) nutzen diesen Mode. Ein RT sendet regelmäßig seinen Status - und hierbei kann man über wakeup mit dem Device alle 3min kommunizieren. Nun muss ein RT aber auf Fensterkontakte reagieren können. Diese senden Asynchron. Man muss also sicherstellen, dass der Fensterkontakt einen Burst sendet und der RT auf Burst reagiert.
	:Conditional Burst wird in einem Register freigeschaltet.		:Conditional Burst wird in einem Register freigeschaltet.
	:Devices mit CondBurst stellen ein Kommando BurstXmit bereit. Hierbei wird von FHEM ein Burst gesendet und eine eventuell anstehende Kommunikation wird durchgeführt.		:Devices mit CondBurst stellen ein Kommando BurstXmit bereit. Hierbei wird von FHEM ein Burst gesendet und eine eventuell anstehende Kommunikation wird durchgeführt.
Zeile 36:		Zeile 36:
	get hm models -f <regexp>		get hm models -f <regexp>
	get hm models -f SD		get hm models -f SD

	===FHEM Kommunikation===		===FHEM Kommunikation===
	FHEM kennt alle Kommunikationstypen und behandelt diese entsprechend. Zu beachten ist, dass ein HM Gerät aus mehreren Entities besteht: Ein Device und ein oder mehrere Kanäle. Man kann mit den Kanälen nicht direkt kommunizieren. Die Kommunikation geht immer über das Device. So ist es in FHEM auch organisiert. Löst man ein Kommando für einen Kanal aus wir dies in die Abarbeitungsliste der Device gestellt. Je nach Kommunikationstyp arbeitet FHEM die Liste schnellstmöglich ab. <br>		FHEM kennt alle Kommunikationstypen und behandelt diese entsprechend. Zu beachten ist, dass ein HM Gerät aus mehreren Entities besteht: Ein Device und ein oder mehrere Kanäle. Man kann mit den Kanälen nicht direkt kommunizieren. Die Kommunikation geht immer über das Device. So ist es in FHEM auch organisiert. Löst man ein Kommando für einen Kanal aus wir dies in die Abarbeitungsliste der Device gestellt. Je nach Kommunikationstyp arbeitet FHEM die Liste schnellstmöglich ab. <br>

← Nächstältere Version		Version vom 13. Juni 2018, 15:07 Uhr
Zeile 41:		Zeile 41:
	Wir haben also gelernt, dass Kommandos, welche FHEM senden will, in den Kommando-Queues der Devices abgelegt werden. Will nun sehen, ob schon alles erledigt ist, oder ob Fehler aufgetreten sind, muss man den Status der Kommando-queue lesen. Dieser wird in den '''Internals''' welche mit '''[[prot]]''' (Protokoll) beginnend ermittelt.		Wir haben also gelernt, dass Kommandos, welche FHEM senden will, in den Kommando-Queues der Devices abgelegt werden. Will nun sehen, ob schon alles erledigt ist, oder ob Fehler aufgetreten sind, muss man den Status der Kommando-queue lesen. Dieser wird in den '''Internals''' welche mit '''[[prot]]''' (Protokoll) beginnend ermittelt.
	*'''protState''':Der gesamt-Zustand der Queue.		*'''protState''':Der gesamt-Zustand der Queue.
	**[[CMDs_done]]: Alle Kommandos übertragen, es sind bei ''der letzten'' Übertragung keine Fehler aufgetreten		**'''''CMDs_done''''': Alle Kommandos übertragen, es sind bei ''der letzten'' Übertragung keine Fehler aufgetreten
	**[[CMDs_done_Errors~~:<no>]]~~: Alle Kommandos übertragen, es sind ~~bei ''der~~ letzten'' Fehler aufgetreten		**'''''CMDs_done_Errors''''': Alle Kommandos übertragen, es sind beim letzten Fehler aufgetreten
	**[[CMDs_pending]]: Es stehen Kommandos zur Übertragung an. Es wird auf die Möglichkeit der Übertragung gewartet. Bspw. auf das Aufwachen eine wakeup Devices.		**'''''CMDs_pending''''': Es stehen Kommandos zur Übertragung an. Es wird auf die Möglichkeit der Übertragung gewartet. Bspw. auf das Aufwachen eine wakeup-Devices.
	**[[CMDs_processing...]]: Die Kommandos aus der Queue werden gerade abgearbeitet. Dies kann je nach Device und Menge auch etwas dauern.		**'''''CMDs_processing...''''': Die Kommandos aus der Queue werden gerade abgearbeitet. Dies kann je nach Device und Menge auch etwas dauern.
	*'''protLastRcv''': Zeitpunkt der letzten empfangenen Nachricht dieses Device		*'''protLastRcv''': Zeitpunkt der letzten empfangenen Nachricht dieses Device
	*'''protSnd''': Zählt die gesendeten Nachrichten und zeigt den letzten Sendezeitpunkt an.		*'''protSnd''': Zählt die gesendeten Nachrichten und zeigt den letzten Sendezeitpunkt an.
Zeile 61:		Zeile 61:
	set hm clearG msgEvents # löscht alle Zähler und ''leert die Kommando-Queue'' '''aller''' Devices		set hm clearG msgEvents # löscht alle Zähler und ''leert die Kommando-Queue'' '''aller''' Devices
	set hm clearG msgErrors # löscht alle Zähler der Devices welche Fehler anzeigen.		set hm clearG msgErrors # löscht alle Zähler der Devices welche Fehler anzeigen.
	Ein Löschen ist gelegentlich sinnvoll, da Fehler kontinuierlich akkumuliert werden. Wenn man die Fehler nun erfasst hat kann man diese zurücksetzen um neu auftretende besser zu erkennen.		Ein Löschen ist gelegentlich sinnvoll, da Fehler kontinuierlich akkumuliert werden. Wenn man die Fehler nun erfasst hat kann man diese zurücksetzen um neu auftretende besser zu erkennen.

	===Kommunikation Timing===		===Kommunikation Timing===
	Die Kommunikation setzt ein straffes Timing der Nachrichtenübermittlung voraus. Eine Nachricht muss in einem Zeitfenster von 100ms-250ms nach senden beantwortet werden. Aufgrund der Natur von FHEM mit IOs welche über unzureichende Betriebssysteme angeschlossen werden kann das Timing nur schwer gewährleistet werden. Verzögerungen durch LAN oder USB müssen berechnet werden		Die Kommunikation setzt ein straffes Timing der Nachrichtenübermittlung voraus. Eine Nachricht muss in einem Zeitfenster von 100ms-250ms nach senden beantwortet werden. Aufgrund der Natur von FHEM mit IOs welche über unzureichende Betriebssysteme angeschlossen werden kann das Timing nur schwer gewährleistet werden. Verzögerungen durch LAN oder USB müssen berechnet werden