KNX/EIB Kommunikation

[chrissfuwa]

Hallo KNX-User,
wie funktioniert das denn mit der Kommunikation? In welchen Zeitabständen wird gesendet? (Ich habe mal etwas mit 500 ms gelesen). Kann man diese Zeit nicht für eigene Zwecke anpassen oder ist diese vom Standard her vorgeschrieben? Leider finde ich bisher nur marketing gerede. Mir fehlen hier irgendwie die Fakten.


Freundliche Grüße,

Chris

[2ndsky]

Die Buskommunikation ist ein Standard. Natürlich kann man den Anpassen, aber immer mit dem Risiko, dass andere Teilnehmer nicht mehr kommunizieren können. Weil sobald du da was änderst ist es kein Standard mehr.

Als Vergleich: wenn du nun beschließt, dass in Deutschland nicht mehr rechts vor links sondern links vor rechts gilt funktioniert das solange gut, bis du mit einem anderen Verkehrsteilnehmer an einer Kreuzung stehst.

EDIT: wie der Standard genau aussieht solltest du auf der Seite der KNX Association finden: http://www.knx.org/knx-standard/knx-specifications/

[Gaston]

Hi Chris,

Könntest Du mal genauer ausführen nach was Du suchst. Gesendet wird ja nur wenn dies nötig ist. Theoretisch kann die Zeit zwischen zwei Telegrammen also sehr lang sein

Deine Frage könnte sich auf die Zeit zwischen 2 bit, bytes, Telegramme beziehen, und bei kletzterem wieder zwischen Anfang von beiden Telegrammen oder zwischen Ende des einen und Anfang des nächsten

Ich gehe mal von letzterem aus:

Der Standard Abstand zwischen zwei Telegrammen beträgt 53bits, was ca. 5.5ms (1bit=104us) entspricht.

Gruss,
Gaston

[chrissfuwa]

Wenn ich das richtig verstanden habe, kann ich also "nur" vorgeben in welchem Zeitabstand eine Kommunikation stattfinden soll:

Sprich "höre alle 10 Minuten auf die Daten des z.B. Heizkörpers".

Die maximale Zeit zur Synchronisierung des Senders und Empfängers beträgt 500 ms?

[Gaston]

Ah, Du sprichst von KNX-RF. Dann vergiss das oben geschriebene.

KNX-RF benutzt die Zentralfrequenz 868.3. Diese Frequenz ist frei zugänglich und genormt. Die Sendedauer ist per Norm begrenzt um Kolisionen zu minimieren und zu verhindern dass Geräte bei hoher Anzahl ausgeschlossen werden.

Laut nor liegt die Benutzungs grenze bei 1% und die maximale Leistung bei 25mW. Laut KNX-RF Norm sind die maximalen Parameter 1% Auslastung und 14dbm(=25mW) Leistung. KNX-RF Nutzt die Verfügbare Leistung also komplett aus.

Gruss,
Gaston

[chrissfuwa]

Ich habe nun bei knx.org mal eine Mail verfasst, um an die Spezifikation zu kommen. Diese wird mich sicherlich weiterbringen und es ermöglichen Ergebnisse zu erarbeiten.

In Bezug auf den Energiebedarf scheint KNX-RF noch höher als Bluetooth low energy zu sein. Gibt es eine Übersicht bzw. einen Vergleich der verschiedenen Standards in Bezug auf Energiebedarf ? Falls nicht, kann ich das mal gerne machen, wenn ich die Daten erfasst habe. Oder wäre ein Vergleich der verschiedenen Standards hier unerwünscht?

Wenn die Kommunikationszeit in der Norm vorgegeben ist, kann ich den Energieverbrauch ja nurnoch über die länge der Telegramme senken oder?

Ansonsten fällt mir spontan keine Möglichkeit den Energieverbrauch zu "drücken".

[Gaston]

Sprich "höre alle 10 Minuten auf die Daten des z.B. Heizkörpers".

KNX-RF hat einen BiBat modus für Batteriegetriebene Geräte. In diesem Modu wird die Kommunikation vom Master zum Slave (Bateriegetriebenes Gerät) in einem Synchronen modus ausgeführt.

Hierfür wird die Zeit in Slots von je 62.5ms aufgeteilt. Ein Block besteht aus bis zu 128 slots, sprich 8 Sekunden. Slaves müssen dabei mindestens auf slot 0 und 64 hören, andere Timeslots könne zwischen Master und Slave ausgemacht werden.

Dies bedeutet dass der Empfänger mindestens alle 4 Sekunden für 62.5ms (+Toleranz) eingeschaltet werden muss.

Gruss,
Gaston

[chrissfuwa]

KNX-RF hat einen BiBat modus für Batteriegetriebene Geräte. In diesem Modu wird die Kommunikation vom Master zum Slave (Bateriegetriebenes Gerät) in einem Synchronen modus ausgeführt.

Hierfür wird die Zeit in Slots von je 62.5ms aufgeteilt. Ein Block besteht aus bis zu 128 slots, sprich 8 Sekunden. Slaves müssen dabei mindestens auf slot 0 und 64 hören, andere Timeslots könne zwischen Master und Slave ausgemacht werden.

Dies bedeutet dass der Empfänger mindestens alle 4 Sekunden für 62.5ms (+Toleranz) eingeschaltet werden muss.

Gruss,
Gaston

Ich habe hier http://www.beteccontrols.nl/UserFile...20systemen.pdf eine Zusammenfassung gefunden. Wie die hierbei auf die Minimale Telegrammlänge kommen ist mir aber ein Rätsel.

[Gaston]

Wie die hierbei auf die Minimale Telegrammlänge kommen ist mir aber ein Rätsel.

Ich habe es jetzt nicht nach gerechnet, aber Ich denke dass die 20ms falsch sind.

Begründung:

In einen Timeslot passen maximal 3 Telegramme was eine Länge von 20ms pro Telegramm plausiebel erscheinen lässt. Jedoch passen diese 3 telegramme nur dann rein wenn sich die 3 Telegramme auf die Gleiche Adresse beziehen, diese also nur im ersten Telegram gesendet werden muss.

Die bedeutet wiederum dass ein Gesammtes Telegram mit der Adresse grösser als 20ms sein muss und und somit die folgenden (abgekürzten)kleiner als 20ms.

Aber das spielt nach dem Standard keine Rolle denn beim Senden kannst Du ja nicht die minale Länge verwenden sondern die die dein Datenpaket eben benötigt. Und beim Empfangen bist Du von den Sendern abhängig. Die Telegramgröse spielt hier eine untergeordnete Role da in einem Time-slot ja 3 Telegrame drin sein können.

U.U. kann man den Receiver nach dem postemble anbchalten und nicht die vollen 62.5ms anlassen. Zumindets ist mir nichts bekannt was dies verbieten würde.

Gruss,
Gaston

[chrissfuwa]

Aber das spielt nach dem Standard keine Rolle denn beim Senden kannst Du ja nicht die minale Länge verwenden sondern die die dein Datenpaket eben benötigt. Und beim Empfangen bist Du von den Sendern abhängig. Die Telegramgröse spielt hier eine untergeordnete Role da in einem Time-slot ja 3 Telegrame drin sein können.

U.U. kann man den Receiver nach dem postemble anbchalten und nicht die vollen 62.5ms anlassen. Zumindets ist mir nichts bekannt was dies verbieten würde.

Gruss,
Gaston

Also ist es nur Möglich Energie einzusparen, wenn ich möglichst kurze Telegramme versende und anschließend den Receiver nach Empfang einer Nachricht sofort "schlafen" lege. Oder gibt es bei KNX RF noch weitere "Einsparungsmöglichkeiten"?

[Gaston]

Also ist es nur Möglich Energie einzusparen, wenn ich möglichst kurze Telegramme versende und anschließend den Receiver nach Empfang einer Nachricht sofort "schlafen" lege. Oder gibt es bei KNX RF noch weitere "Einsparungsmöglichkeiten"?

Oki, hab mich wohl irgendwie schlecht ausgedrückt. Also von corne und langsam:

1. Frage: soll das teeil das Energiesparen muss nur senden oder auch empfangen ?

[chrissfuwa]

Das "Teil" bezieht seine Energie per Harvesting. Es sollte sowohl senden als auch Empfangen.

[Gaston]

Also das mit den Telegrammen sehe Ich nicht als Energiesparmassnahme da Du ja die telegramme verwenden musst die für die Funktion nötig sind. Natürlich sind 1-bit Datentelegarmme kleiner als 14 Byte Textmeldungen.

Das Senden kann asynchr, das heisst zu jedem X-beliebigen Zeitpunkt stattfinden und muss nur nach Bedarf gemacht werden. Hier spart man also einfach durch die Senderate der Telegramme.

Der Vollständigkeitshalber: Bei BiBat Geräten die synchron arbeiten (Empfänger) gibt es zum senden bevorzugte Time-slots. !andert aber nichts am Energieverbrauch.

Das Empfangen geht synchron damit der batteriebetriebene Empfänger seinen Empfänger zum Energiesparen ausschalten kann. In einem Intervak von 8 Sekunden (128 time-slots) muss der Empfänger mindestens 2x an sein (slot 0 & 64). Des weiteren können Ihm im Bereich 65-127 weiter etimesolts zugewiesen werden.

Als Minimum muss der Empfänger also alle 4 Sekunden für 62.6ms +Synchronitätstoleranz eingeschaltet werden.

Gruss,
Gaston