Guten Morgen Zusammen, Als erstes eine kurze Einleitung: Ich habe vor, dieses Jahr einen Open-Source-Bus auf CAN Basis zu implementieren. Und dies mit mehreren Firmen zusammen. Die Anforderungen sind ähnlich wie bei KNX (Spannung und Signal via 2-Draht), jedoch mit einem "Master/Controller" bzw. einer SPS. Der Bus wird Asynchron sein und es werden Elektronik-Module hergestellt. Diese sollen aber Nachbaubar sein OHNE Lizenzen. Gleichermassen die Software. Das Protokoll soll unabhängig von Medien sein. Sprich auch via Funk oder PowerLine kompatibel bleiben. Er darf keine "120 Ohm Einbau-Wiederstände" enthalten. Diese kann ein 0815 Elektriker nicht vernünftig verbauen. Die Versorgungsspannung beträgt 24V Nominal. Die Baud-Rate soll bei ca. 9600 oder höher liegen. Dies werde ich nochmals in den Feldversuchen/Praxistests definieren. Die ID von jedem Gerät wird eindeutig Definiert. Das Gerät wird dadurch bei einem Scan automatisch erkannt. Die Idee dahinter ist ganz einfach: Kostengünstiger Bus für jedes Haus. Zukunftssicher. Herstellerunabhängig. Ich finde dies sollte bereits heute Standard sein! Die Lösung für Software und Protokoll kann ich bereits beisteuern. Auch die Geräte werden kein Problem sein. Am Bus selbst arbeiten wir noch. Bisher habe ich das mit dem Voltage-Level-Shifting noch nicht herausgefunden. Ev. hat einer dazu eine Idee? Auch andere Vorschläge sind Herzlichst Willkommen! PS: Die Resultate sind für die Allgemeinheit und nicht um Profit zu machen. Der Profit soll über die Software gehen und über den Verkauf von Servern und nicht von Bussystemen. Das Bussystem soll dann auch im Haus bleiben können wenn es die Firma schon nicht mehr gibt. Deshalb bitte ich euch auch Sachlich zu bleiben. Danke.
:
Verschoben durch Moderator
PPS: Die Seite "https://www.mikrocontroller.net/articles/Hausbus_Diskussion"; habe ich bereits gelesen. Nur leider hat das Projekt wenig Erfolg. Bitte gebt auch Wünsche und Mittel an, die weiter euch helfen können. Z.B. könnten wir eine Webseite zur Entwicklungshilfe erstellen oder ähnliches? Vielen Dank
ein EIB/KNX Kabel hat 4 Adern wieso also nicht Versorgungsspannung und Daten aufteilen dann muss man da nichts aufmodulieren sondern nimmt normale CAN-Treiber und hat ein Kabel das auch mit Zusammenverlegung von 230V Leitungen zugelassen ist.
Markus S. schrieb: > Die Anforderungen sind ähnlich wie bei KNX > (Spannung und Signal via 2-Draht), jedoch mit > einem "Master/Controller" bzw. einer SPS. Habt ihr euch auch den M-Bus angeschaut? Ich bin mir gerade nicht sicher, was die maximalen Übertragungsraten sind, aber ansonsten könnte der eure Anforderungen erfüllen. Ist gut dokumentiert, der Physical Layer ist sehr robust (es gibt mit "Wireless M-Bus" sogar eine Drahtlosvariante), und von TI gibt es fertige Treiber (TSS521/TSS721, kann man aber auch leicht diskret aufbauen). Protokollseitig könnt ihr euch dann immer noch austoben. http://www.m-bus.com/mbusdoc/default.php Ein weiterer Vorteil: Er wird in einigen weit verbreiteten kommerziellen Produkten (z.B. meiner Viessmann Heizungssteuerung) verwendet, so dass man vielleicht die Möglichkeit hat auch bereits erhältliche Sensoren, Aktoren, etc. einzubinden (wobei man dazu wahrscheinlich Abstriche beim Protokolldesign machen müsste).
Wirklich sinnvoll wäre ein galvanisch getrennter Bus, wie das z.B. bei MIDI der Fall ist. Das würde es auch erlauben, Geräte mit z.B. Kondesatornetzteil anzusteuern und einen vor lästigen Schleifen zu bewahren.
:
Bearbeitet durch User
>> Diese sollen aber Nachbaubar sein OHNE Lizenzen. Gleichermassen die Software.
Kann ich mich von die eine seite vorstellen, von die andere seiten
klappen viele Projekten nicht oder schwierig wenn die separate Produkten
nicht garantiert die Spezifikationen erfuellen. Meine erfahrung ist auch
das das verknuepfen von funktionalitaet der einzelen Produkten viel zeit
und noch mehr geld kostet.
Ich spreche nicht ueber kleine (Hobby) Projekten aber professionele
Projekten.
Vergleich : Wenn ein Anhaengerkupplung nicht genau an die Richtlinien
trefft, gibt es eine chance das er nicht auf jedem Auto zu benutzen ist.
PS : Ich schreib dies nur um diese Meinung in deine ueberwegung
mitzunehmen und nicht zu leicht darueber zu denken. Es gibt schon sehr
viele leuten/geschaeften die gute ideeen hatten ueber bussystemen aber
die es nicht geschafft haben.
Naja... Ich finde die Idee eines "Offenen Hausbusses" interessant. Mache mir aber Sorgen über die Angreifbarkeit. Da krankelt es bei einigen Systemen ... Der Einbrecher braucht nur Zugang, zu einem Bewegungsmelder am Bus, und kann draußen mit dem Läptop auf dem Schoß warten, bis alle Bewohner weg sind und die Alarmanlage vom Auto aus deaktivieren.
Hi Markus, ich finde die Idee sehr gut! Grund: ich baue selber Hausbussysteme. OpenSource ist dabei wichtig! Ich würde CAN bevorzugen, denn dies ist mit Softwareanpassung und einem uC mit integrierten CAN-TRX auch als RS485 nutzbar. 4 Draht ist ausreichend, da normalerweise überall mindestens JY/St)Y 2x2x0,x verlegt ist (Telefonleitung mit Schirm). Anschlussterminals für die Datenleitung also 5 Polig. Buswiderstände normalerweise nicht nötig da nur am Anfang (Zentrale) und am Ende nötig. Da kann man eigendlich ein Termination-R-modul einsetzen. Wie macht ihr das mit der Adressierung? Dip-Schalter oder feste Seriennummer mit nem IC? Es würde sich dann ein EEPROM mit EUI48 wie 2AA02E48 anbeiten. Ist ein EEPROM mit einer MAC-Adresse. Die Ansteuerung der Module sollte übrigends in FHEM oder OpenHAB unterstützt werden! So wie bei 1Wire etc. Grüße Alex
Arduino F. schrieb: > Naja... > > Ich finde die Idee eines "Offenen Hausbusses" interessant. > Mache mir aber Sorgen über die Angreifbarkeit. > > Da krankelt es bei einigen Systemen ... > > Der Einbrecher braucht nur Zugang, zu einem Bewegungsmelder am Bus, und > kann draußen mit dem Läptop auf dem Schoß warten, bis alle Bewohner weg > sind und die Alarmanlage vom Auto aus deaktivieren. "offen" ist bestimmt im Sinne von "Open Source/Hardware" gemeint, nicht im Sinne von "keine Security".
THOR schrieb: > "offen" ist bestimmt im Sinne von "Open Source/Hardware" gemeint, nicht > im Sinne von "keine Security". Das ist mir schon so klar.... Habe aber hier noch nichts von "Security" gehört. Mir wäre "Security" wichtig, um ein solches System empfehlen zu können.
Security muss nicht zwingend im Bus implementiert werden, dass kann auch auf der Transport- oder Anwendungsschicht passieren. Man muss sich nur Gedanken machen, was später am Bus dranhängen soll. Kann ein Angreifer den Schliessbefehl für die Haustür verhindern sodass dann die Tür nachts offen ist? In dem Fall liegt der Fehler nicht beim Bus der keine Security implementiert hat, sondern am Software-Schreiber der von uneingeschränkt zuverlässiger Buskommunikation ausgegangen ist. Security im Bus ist sogar leicht grenzwertig, da single point of failure: Sobald die Bus-Security geknackt ist, kann ein Angreifer gleichzeitig die Haustür öffnen und die Alarmanlage abstellen.
Vergess auch nicht das man fuer ein professionellen bus-system die folgende sachen unbedingt unterstuetzen soll : * Software upgrade von embedded software ueber den netz. Du schlagst 9600 baud vor. Dann kann man das vergessen. Machdem so etwas dann noch einbauen geht nicht mehr. * Dezentrales system - Man musz nicht die situation haben wenn die zentrale aus faellt (oder teilweise strom des Gebaudes) das dann alles stoppt. Du gibs and es wird ein zentrales system. Meiner meinung ist die definition damit schon nicht zukunftfaehig. Ja, ich weisz es ist einfach fuer mich auf deine definitionen zu 'schiessen' aber vergess nie die gedanke die T... (bitfehler) schon angab : https://xkcd.com/927/ Warum das rad neu erfinden ?
THOR schrieb: > Security muss nicht zwingend im Bus implementiert werden, dass kann auch > auf der Transport- oder Anwendungsschicht passieren. > > Man muss sich nur Gedanken machen, was später am Bus dranhängen soll. > Kann ein Angreifer den Schliessbefehl für die Haustür verhindern sodass > dann die Tür nachts offen ist? > In dem Fall liegt der Fehler nicht beim Bus der keine Security > implementiert hat, sondern am Software-Schreiber der von uneingeschränkt > zuverlässiger Buskommunikation ausgegangen ist. Das Konzept ist aber grenzwertig. Wozu dann überhaupt einen eigenen Bus definieren. Wenn alles was interessant ist, den Anwendungen überlassen wird? Security/Verschlüsselung und natürlich auch Arbitrierung, Auto Retransmit/Ack, Staukontrolle, Flußkontrolle usw. sind ja gerade die interessanten Dinge die man in das Konzept packen muss. Sonst nehm ich RS232 oder RS485 und fertig ist der neue Hausbus? Stell dir vor, TCP/IP müsste von jeder Netzwerk- oder Internetanwendung wieder selbst mitgebracht werden. Inklusive TLS Verschlüsselung. PS: Mit dem Begriff "Bus" verbinde ich jetzt mal das ganze Konzept, welches natürlich aus mehreren Schichten bestehen kann.
:
Bearbeitet durch User
Hallo. Ich habe ein ähnliches Projekt, allerdings habe ich versucht mich weitgehend an Industriestandards zu halten. Ich verwende CANopen und eine zentrale Steuerung. Bei KNX Kabel sollten 100 Teilnehmer und 500m problemlos möglich sein. Eine erste kleine Testanlage läuft seit 6 Monaten ohne Probleme. Zur Zeit wird die Hard- und Software überarbeitet um einen EMV Test zu überstehen. Christian_RX7
Cyblord -. schrieb: > natürlich auch Arbitrierung, Auto > Retransmit/Ack, Staukontrolle, Flußkontrolle usw. sind ja gerade die > interessanten Dinge die man in das Konzept packen muss. Das macht die CAN-Peripherie in Hardware. Deswegen auch CAN. > Sonst nehm ich RS232 oder RS485 und fertig ist der neue Hausbus? RS232 ist kein Bus, sondern Punkt-zu-Punkt. Und RS485 definiert nur Spannungspegel, nicht aber Kollisionserkennung, Paketformat etc. fchk
Frank K. schrieb: > Cyblord -. schrieb: >> natürlich auch Arbitrierung, Auto >> Retransmit/Ack, Staukontrolle, Flußkontrolle usw. sind ja gerade die >> interessanten Dinge die man in das Konzept packen muss. > > Das macht die CAN-Peripherie in Hardware. Deswegen auch CAN. ja aber CAN macht halt nur einen Teil. > >> Sonst nehm ich RS232 oder RS485 und fertig ist der neue Hausbus? > > RS232 ist kein Bus, sondern Punkt-zu-Punkt. Und RS485 definiert nur > Spannungspegel, nicht aber Kollisionserkennung, Paketformat etc. Aber CAN macht eben z.B. keine Verschlüsselung oder Authentifizierung. War ein Beispiel. Außerdem kann ich RS232 auch als Bus betreiben. Da gibt's genügend Beispiele. Es reicht ja die ganze ID Geschichte in die Anwendung zu verlagern ;-) Es ist ja sinnvoll als unterste Schicht CAN zu verwenden und dessen Vorteile hier mitzunehmen. Aber oben drauf fehlt da halt noch was. Das alles in die Anwendung zu verlagern gibt Chaos und macht das ganze Fehleranfällig.
:
Bearbeitet durch User
Markus S. schrieb: > Er darf keine "120 Ohm > Einbau-Wiederstände" enthalten. Diese kann ein 0815 Elektriker nicht > vernünftig verbauen. Wieso nicht? Bei ISDN geht das seit 30 Jahren. Du kannst die Physik nicht ändern. Bei einem Bus brauchst Du Terminierungswiderstände, um keine Leitungsreflektionen an den offenen Enden zu haben. > Die Versorgungsspannung beträgt 24V Nominal. Ungünstig. ISDN und PowerOverEthernet verwenden 48V. Das ist übliche Telco-Spannung und fällt auch noch unter Sicherheitskleinspannung. Du willst mit der Spannung so hoch wie möglich gehen, um die Spannungsverluste in den Leitungen zu minimieren. > Die > Baud-Rate soll bei ca. 9600 oder höher liegen. Die Bitrate MUSS deutlich größer als 10...12kbit sein, weil sonst in den CAN-Transceivern Timeouts ablaufen, die die Dauer von dominanten Zuständen (logisch 0) auf dem Bus begrenzen, die durch irgendwelche Gerätefehler entstehen können. Ein Gerät soll den Bus eben nicht dauerhaft blockieren können. > Bisher habe ich das mit dem Voltage-Level-Shifting noch nicht > herausgefunden. Ev. hat einer dazu eine Idee? Ist doch alles vorhanden. Nimm für die Verkabelung Sternvierer, wie sie für Telefone verwendet werden, und gut ist. Ein Paar strägt die 48V Versorgungsspannung, das andere Paar die Daten. Am Besten 48V-tolerante CAN-Transceiver verwenden (zB MAX1305x, https://datasheets.maximintegrated.com/en/ds/MAX13050-MAX13054.pdf ), ESD-Schutz und stromkompensierte Drossel davor (die übliche Automotive-Schutzschaltung, die die gängige Literatur zeigt), und los gehts. Als Controller reicht ein PIC18F26K80 (http://www.microchip.com/wwwproducts/en/PIC18F26K80), der hat ein ECAN eingebaut. Als Schaltregler zum Wandeln der 48V nach 5V nimmst Du den TPS54060A http://www.ti.com/lit/ds/symlink/tps54060a.pdf Damit sind die wesentlichen technischen Probleme erledigt - der Rest ist Datenblatt Lesen. fchk
Ich werde mich später wieder melden wir erarbeiten ein Konzept. Bis jetzt ist wohl wirklich 4 draht mit 24V separat gut geeignet. So können auch andere Komponenten mitgespiesen werden. Der CAN wird als Bus genommen. Adressierung Fix oder per Zufall inkl. Lerntaste und LED so fällt die Identifikation einfach aus. Die Programmierung wird wie bei KNX Dezentral aber auch Zentral möglich sein. Somit ist die Installation ohne Master lauffähig. Punkto Sicherheit werden noch Überlegungen folgen. Für mich als Integrator kenne ich dies auch nicht von KNX. Das Protokoll wird nur schwerer zu verstehen bei der Fehlersuche. Ev. Kommt dies dann eher bei RF und Ethernet zustande. Am Buskabel wirds womöglich nicht gehen. Ev. Hat ja einer eine Idee bevor das Protokoll beim hochstufen inkompatibel wird. Wer EnOcean kennt weiss das es früher schon versuche mit Verschlüsselung gab diese wurden aber wieder verforfen (Siehe EnOcean ESP3.0). Man müsste nur noch eine Art ETS entwickeln. Diese soll auch OpenSource und völlig frei sein. Dies und noch mehr werden wir noch erarbeiten. Vielen Dank für den Tipp mit dem ECAN MC und allen anderen Anregungen.
Hallo, ich arbeite gerade an einer komplett Open Source Protokollspezifikation inclusive Beispieltreiber. Sie wird transportunabhängig, sicherbar und skalierbar sein. Hintergrund ist, dass ich seit 20 Jahren in der Protokollspezifikation und -implementation in Embedded aktiv bin und schon unzählige Protokolle realisiert habe. Eines meiner letzten Protokolle läuft bereits sehr stabil in kommerziellen Umgebungen, und ich denke, dass ich über die Anfängerfehler hinaus bin. Der erste draft wird demnächst zur Verfügung stehen, und ich möchte die Spezifikation in einem möglichst offenen Prozess erstellen. Das einzige was ich nicht weiss ich wie ich "den Daumen drauf halten" kann - NICHT um wirtschaftliche Vorteile davon zu haben (die Initiative wird non profit, ausser wenn Jemand Consultinghilfe bei der Umsetzung in Anspruch nehmen will) sondern damit das Protokoll in einer Hand bleibt und nicht in 27 proprietäre branches zerfällt und Jeder sein eigenes Süppchen daraus kocht. Weiss Jemand, wie man so etwas sinnvoll angeht?
Moin, spannendes Vorhaben, aber macht's bloss nicht kompliziert. Ein paar Anmerkungen: - Terminierung ist zwingend, das mit der Physik wurde schon gesagt. - Neben Ethernet, CAN, RS485/modbus wird es schwierig, ein neues physikalisches Protokoll zu verteidigen. Mir persönlich dürfte es eine verbesserte modbus-RTU-Implementierung sein. - Software-Updates über den Bus sind eigentlich verboten. Also darf der Bus ruhig langsam sein. Wichtig ist Robustheit und genau definierte Timeouts. In so einigen Gebäudeanwendungen geht es um Sensorik der sicherheitsrelevanten Art (Luftqualität), dahingehend würde ich Verkaufsargumente für neuartige Busse steuern. Ruediger A. schrieb: > nehmen will) sondern damit das Protokoll in einer Hand bleibt und nicht > in 27 proprietäre branches zerfällt und Jeder sein eigenes Süppchen > daraus kocht. > > Weiss Jemand, wie man so etwas sinnvoll angeht? Ich hätte schon einige Ideen, aus Erfahrung mit diversen Standardisierungsgremien kann ich leider nur berichten, dass die cleveren Lösungen seltenst das Rennen machen und die Platzhirsche im Geschäft gehörig blockieren können, wenn sie sich übergangen fühlen. Ich würde das Problem im "stealth mode" lösen. Bloss nicht zuviel ankündigen, und zunächst im kleinen Kundenkreis etablieren. Dann setzt du ne Webseite auf, nennst ein paar Referenzprojekte und bietest eine Testbench/Zertifizierung an. Ich würde mich einfach markenrechtlich soweit vorbereiten, dass du einen registrierten Namen für deinen "Standard" hast. Wenn dein Standard gut ist, ist es auch durchaus legitim, dass du trotz OpenSource manchen Mitspielern untersagen kannst, sich mit dem "Schnorf-Standard-compliant" Logo zu schmücken, wenn die Testbench nicht bestanden ist. Also z.B. so wie bei GigE, USB, usw. Nur den Bockmist der VID-PID-Registrierung würde ich nicht gerade wiederholen, das nervt wohl jeden Entwickler. Bei der Testbench ist die Frage, wie man das am besten angeht. Da fiele mir spontan ein: - Simulationsmodell als Executable mit virtuellen I/O - Compliance-Testgerät (Hardware zum Kaufen) Das ist aber alleine schon gehörig aufwendig, vielleicht will man da dann eine (nicht allzugrosse) Firma mit ins Boot holen. Die Frage ist nur noch, wie weit du beim Zwang zur OpenSource dann schliesslich gehen willst. Darf ein Hersteller z.B. dein Protokoll physikalisch nutzen, aber logisch verstümmeln, dass es proprietäre Bibliotheken zur Ansteuerung benötigt, usw.
2drahtbus ist immer ein Kompromis. Entweder Leitungslänge oder Stromstärke oder Geschwindigkeit. Alles zusammen geht halt nicht und die Teilnehmeranzahl ist auch begrenzt. Von Esser gibts einen wunderschönen proprietären 2 Draht Bus für Brandmeldeanlagen mit vielen tollen Features. Einfehlertoleranz auf Drahtbruch und Kurzschlüsse (!!!) mit Anzeige des Defektes an der Zentrale, Autoadressierung per Software, automatisches einscannen von Busstrukturen mit Ring und Stichleitungen, Alarm bei entnommenen/defekten Teilnehmern usw. Die 4 Drahtleitungen werden übrigens zum Schliessen des 2-Draht Rings genommen was dann auch ohne Abschlusswiderstände an den Teilnehmern geht. Bis zu 127 Teilnehmer auf 3500m Länge mit J-Y(St)Y 0,8mm wobei dann nicht mehr jeder arg viel Strom entnehmen darf. Als Nachteil ist das System arschlangsam aber zum Ansteuerern einzelner I/O, technischer Alarme, Lichtkuppeln usw. noch gut genug. Mit der Nennspannung sind die übrigens auch mal nach oben gegangen um mehr Leistung zu kriegen. Komplexere Teilnehmer, Relaiskarten, Magnete, Antriebsmotoren, Bedientableaus usw. brauchen aber allemal eigene Versorgungsspannung. Kleinere Sensoren, Lautsprecher o.ä. haben Cmos uC und versorgen sich aus dem 2-draht Bus.
Oboendieb schrieb: > - Terminierung ist zwingend, das mit der Physik wurde schon gesagt. Kommt doch auf die Länge, die Geschwindigkeit und die verwendeten Treiber an. Alle diese Dinge wurden hier noch nicht definiert, also (noch) nicht zwingend. RS485 z.B. mit passenden Treibern ist seeeehr robust auch ohne Abschluss. > - Software-Updates über den Bus sind eigentlich verboten. Also darf der > Bus ruhig langsam sein. Wieso? Gibt es da eine Norm die darauf anwendbar wäre und dies verbietet? Für welche Geräte wäre das verboten? Das würde mich wirklich interessieren. Für'n Privatbereich kannst natürlich updaten und diese Feature ist IMHO heutzutage zwingend. Aber auch im kommerziellen Umfeld wüsste ich jetzt nicht, was dagegen spricht. Markus S. schrieb: > Protokoll soll unabhängig von Medien sein. Sprich auch via Funk oder > PowerLine kompatibel bleiben. Da wird die Sache dann kompilziert, finde ich. Denn in jedem Protokoll brauchst du irgendwelche Timingkriterien. Und wenn's nur um die Zeit geht bis du einen Ausfall erkennst, oder ein Senderetry anstößt. Wenn du die Timings sehr groß machst, z.B. für eine Funkverbindung mit Gateway, dann hast du automatisch nur geringen garantierten Durchsatz (unabhängig von der Baudrate). Oder meinst du auf garantierte Antwortzeiten/Durchsatz verzichten zu können?
Andi B. schrieb: > Da wird die Sache dann kompilziert, finde ich. Denn in jedem Protokoll > brauchst du irgendwelche Timingkriterien. Und wenn's nur um die Zeit > geht bis du einen Ausfall erkennst, oder ein Senderetry anstößt. Es gibt ja nun Protokolle auf verschiedene Ebenen. Bitaustausch und Timings finden auf unterster Ebene statt und werden sozusagen mit dem physikalischen Medium zusammen ausgetauscht. Das interessante sind deine Protokolle höherer Ebenen und DIE sollten allgemein sein. Und natürlich solltest du erst mal ein solches Schichtenkonzept vorsehen. Wer alles in einer Schicht abhandelt und bei jeglichen abstrakteren Aufgaben, gleich wieder auf das letzte Bit achten muss, der macht ein extrem festgezurrtes, nicht erweiterbare und schlecht wartbares Protokoll.
Andi B. schrieb: > Oboendieb schrieb: >> - Terminierung ist zwingend, das mit der Physik wurde schon gesagt. > > Kommt doch auf die Länge, die Geschwindigkeit und die verwendeten > Treiber an. Alle diese Dinge wurden hier noch nicht definiert, also > (noch) nicht zwingend. RS485 z.B. mit passenden Treibern ist seeeehr > robust auch ohne Abschluss. > Kann robust sein. Aber eben nur kann, muss nicht. Ich will auf jeden Fall keinen neuartigen Bus sehen, der Probleme mit Leitungsreflexionen bei hohen Bitraten zeigt. >> - Software-Updates über den Bus sind eigentlich verboten. Also darf der >> Bus ruhig langsam sein. > > Wieso? Gibt es da eine Norm die darauf anwendbar wäre und dies > verbietet? Für welche Geräte wäre das verboten? Das würde mich wirklich > interessieren. > Ich weiss nicht, was SIL-3 diesbezüglich vorschreibt, aber es ist nicht erwünscht, dass Sensoren durch ein fehlerhaftes oder gar schadhaftes Neuprogrammieren falsche Werte liefern, mal abgesehen davon, dass jede Firmware-Version einzeln zertifiziert werden muss. Für den Hausgebrauch kann man ja schon was frickeln. Aber die Kunden wollen das Feature wirklich zuletzt, da darf nur ein Techniker ran. > Für'n Privatbereich kannst natürlich updaten und diese Feature ist IMHO > heutzutage zwingend. Aber auch im kommerziellen Umfeld wüsste ich jetzt > nicht, was dagegen spricht. > Sicherheit und Haftung. Wenn ein CO-Sensor einen falschen Grenzwert liefert, wird's lebensgefährlich. Hindert dich aber ja nicht dran, für dein Gerät ein OTA-Update zu implementieren. Muss nur nicht in ne Bus-Spec. > Markus S. schrieb: >> Protokoll soll unabhängig von Medien sein. Sprich auch via Funk oder >> PowerLine kompatibel bleiben. > > Da wird die Sache dann kompilziert, finde ich. Denn in jedem Protokoll > brauchst du irgendwelche Timingkriterien. Und wenn's nur um die Zeit > geht bis du einen Ausfall erkennst, oder ein Senderetry anstößt. Wenn du > die Timings sehr groß machst, z.B. für eine Funkverbindung mit Gateway, > dann hast du automatisch nur geringen garantierten Durchsatz (unabhängig > von der Baudrate). Oder meinst du auf garantierte > Antwortzeiten/Durchsatz verzichten zu können? Aus Erfahrung kann ich bestätigen, dass das schwierig wird. Teils ist es dann einfacher, das Gerät einfach mit Ethernet auszustatten. Oder alles irgendwie über abonnierte Daten a la MQTT zu vernetzen. Wo wir wieder beim Thema wären, warum nicht alles im Haus zum IoBS hinzugefügt werden sollte... Ein uniformer EWMS (eierlegende...) Bus ist von den Kunden auch oft gar nicht gewünscht, denn sie wollen auch ihre Profibus to Ethernet-Gateways verkaufen. Finde ich auch die pragmatischste Lösung.
Hallo, hier eine unabhägige Weiterführung des threads Beitrag "Re: Opensource 2-Draht Hausbus" : Cyblord -. schrieb: > Andi B. schrieb: >> Da wird die Sache dann kompilziert, finde ich. Denn in jedem Protokoll >> brauchst du irgendwelche Timingkriterien. Und wenn's nur um die Zeit >> geht bis du einen Ausfall erkennst, oder ein Senderetry anstößt. > > Es gibt ja nun Protokolle auf verschiedene Ebenen. Bitaustausch und > Timings finden auf unterster Ebene statt und werden sozusagen mit dem > physikalischen Medium zusammen ausgetauscht. Das interessante sind deine > Protokolle höherer Ebenen und DIE sollten allgemein sein. Und natürlich > solltest du erst mal ein solches Schichtenkonzept vorsehen. Wer alles in > einer Schicht abhandelt und bei jeglichen abstrakteren Aufgaben, gleich > wieder auf das letzte Bit achten muss, der macht ein extrem > festgezurrtes, nicht erweiterbare und schlecht wartbares Protokoll. Ja, und das ist auch genau mein Ansatz - ich werde die Spezifikation sehr streng nach dem Modell ISO/OSI trennen, bei layer 2 anfangen (der weder von irgendeiner Physik unterhalb noch irgendwelchen konkreten Anwendungen oberhalb abhängt). Dort wird das framing definiert sowie ein Framegenerator und ein Frameparser implementiert. Layer 3 (Adressierung) wird angesprochen, aber ausser der Vorgabe, wie ein Knoten in einem Bus angesprochen wird, nicht spezifiziert (also Adressvergabe, KOnfliktarbitrierung etc nicht festgenagelt). Dann folgt Sequenzierung und das Format der Nutzdaten (immer noch losgelöst von konkreten Anwendungsfeldern), und später folgen dann Anwendungsprofile (also z.B. Home Automation, Sensorik, Alarmanlagen, ZK etc), wobei ich selber mich aus naheliegenden Gründen auf die Bereiche beschränke, in denen ich eigene Erfahrungen habe. Aus dieser Strategie folgt zwingend, dass keinerlei Timingvorgaben an sich im Protokoll spezifiziert sind; das Protokoll muss es nur leisten, möglichst vielen (von der Physik, der Netzwerktopologie und der Anwendung gegebenen Vorgaben gerecht werden zu können. Über weitere Gedanken und Input (sowohl hier im VOrfeld als auch später bei der Basisspec und konkreten Spezifikation von Applikationsprofilen) freue ich mich sehr!
Also erst Mal vielen ernst gemeinten Dank für die sehr konstruktiven und hilfreichen Ideen und Gedanken! :-) Ich habe einen separaten thread zu meinem Projekt gestartet: Beitrag "RFC: Open Source Bus Protokollspec" und wünsche dem TO, dass er an dieser Stelle mehr sachdienliche Hinweise für sein konkretes Anliegen bekommt!
Uhm, irgendwie hat der Moderator hier Müll gebaut und meinen neuen thread wieder hier zurück gebaut, was soll das bitte?
>> - Software-Updates über den Bus sind eigentlich verboten. Also darf der >> Bus ruhig langsam sein. > > Wieso? Gibt es da eine Norm die darauf anwendbar wäre und dies > verbietet? Für welche Geräte wäre das verboten? Das würde mich wirklich > interessieren. > Oboendieb schrieb: > Ich weiss nicht, was SIL-3 diesbezüglich vorschreibt, Man kann doch keine Sicherheitsanforderung auf einen Bus anwenden wollen solange man noch nicht mal die Funktionalität des Gesamtsystems definiert hat. Sicherheit gegen Gefährdung kann man auf viele Arten erreichen. Ein update einzelner Busteilnehmer alleine, darf im Gesamtsystem halt keine Gefahr verursachen. Oboendieb schrieb: > Sicherheit und Haftung. Wenn ein CO-Sensor einen falschen Grenzwert > liefert, wird's lebensgefährlich. Wenn bei Ausfall eines CO-Sensors, und nichts anderes ist ein falsch gelieferter Wert, eine Gefahr droht, dann hat das System nicht nur diesen einen Sensoren um die Gefahr zu erkennen, und auch eine Menge Plausibilitätschecks dahinter. Wenn während eines Updates eine Gefährdung vom Gesamtsystem nicht erkannt werden könnte, dann muss man halt die Sicherheit anders gewährleisten. Generell zu sagen, Firmware update darf nicht sein, ist falsch. Auch in Autos ist das selbstverständlich erlaubt.
Ruediger A. schrieb: > Uhm, irgendwie hat der Moderator hier Müll gebaut und meinen neuen > thread wieder hier zurück gebaut, was soll das bitte? Ich wars nicht, kann es aber nachvollziehen: in Projekte&Code wird zuerst ein komplettes Projekt vorgestellt. Und dann darüber diskutiert. Ein Projekt das irgendwie ohne Diskussionsgrundlage beginnt, hat dort erst mal nichts zu suchen. Wenn es dann wirklich was zum Nachbauen gibt und das Konzept steht, dann kann es dort rein. Ausserdem gehört der ganze Thread eh' nach Haus&Hof...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.