Hallo, mal eine Grundlegende Frage, im CANBUS heißt es ja das jede ID nur einmal vorkommen soll, um Kollisionen zu verhindern. heißt auch das die ID ja nur in einem Device vorhanden sein darf. jetzt hab ich dazu Folgendes Beispiel im Bus befinden sich : 1 Controller der Lampe1 an/aus schalten kann 1 Controller mit Taster1 um Lampe1 schalten zu können 1 Controller mit Taster2 um Lampe1 schalten zu können 1 Controller der grafisch darstellt ob die Lampe1 leuchtet oder nicht. bedeutet ich brauche allein dafür 3 ID`s ? 1.ID : Zustand Lampe 2.ID : vom Controller mit Taster1 zur Lampe 3.ID : vom Controller mit Taster2 zur Lampe ist mein Denkansatz korrekt? ich finde für diese eine Lampe werden allein schon sehr viel ID´s gebraucht?
Doch, bei diesem System stimmt das schon. Allerdings musst du beachten, dass du in einer Message bis zu 256 Lampen unterbringen kannst ;)
das dachte ich auch erst... aber manche lampen (soll ja nicht nur eine Lampe und zwei Taster werden ) brauchen allein ein ganzes byte zwecks Dimmung... ich weiß nicht ob es vielleicht sinn machen würde wenn ich den bereich der Dimmung nur in 20 schritte unterteile so das ich 10-13Lampen unterkriege...
gerad hab ich festgestellt das ich höchstens 15Lampen in meiner 1-Raum-Wohnung habe, sodas das ganze auch mit analogen werten kein Problem sein sollte :D gut aber wenn du sagst das das nicht anders geht mit den ID´s bedank ich mich schon mal. trotzdem finde ich das irgendwie ganz schön verschwänderisch :D aber Deutschland hats ja :D
Jede Message auf dem Bus sollte nur von einem Gerät gesendet werden, kann aber von mehreren empfangen werden. Pro Message hast du auchganze 8bytes an Daten zur Verfügung .. Da macht es doch Sinn eine LampControlMessage zu definieren, die die lampenadresse und die Helligkeit definiert. Da du wahrscheinlich nicht wirklich oft zwei Taster gleichzeitig drückst kommt es auch nicht zu kollisonen ...und selbst wenn ist es egal da deine buslast wohl gegen 0 geht ;)
selbst mit 11bit Identifiert gehen schon vieeeele Botschaften...zur Not 29bit extended Identifier wenn es nicht reicht ;-)
an die Sache mit den Taster hab ich nicht gedacht... also das ich die nicht gleichzeitig drücke... vielen dank für die gute idee... da kann ich viele ID´s einsparen :) quasi Kollisionsschutz durch zu kurze Arme :D PS: die 11Bit reichen lange das stimmt wohl aber ich möchte es irgendwie auch bissel hübsch programmiert haben :)
:
Bearbeitet durch User
Christoph Herzog schrieb: > PS: die 11Bit reichen lange das stimmt wohl aber ich möchte es irgendwie > auch bissel hübsch programmiert haben :) Denn nutz diese 11 Bit. Was ist denn hübsch daran eine Kollision nicht zu vermeiden. Jeder Knoten bekommt seine eigene ID. Im ersten datenbyte die lampenadresse und anschließend die "dimmung" noch hübschwer wäre es, wenn jede lampe einen bereich von ids hat und die anderen herausfiltert. so könnte diese mit einem taster bedient werden der in ihrem adressbereich liegt und und und... git viele möglichkeiten wie du dein cannetz aufbauen kannst. kollisionen sollten aber auf keinen fall möglich sein! schau dir auch mal can-open an....
Ich habe es so verstanden: der Identifier ist der " Name der Nachricht". Die hat dann noch einen Inhalt, ich glaube maximal 8 Byte.
Hallo Christoph, sorry daß ich das jetzt so schreiben muss: CANBUS ist für dein Ansinnen (egal ob 1- oder x-Raum, und ob 15 oder 1500 Lampen was auch kein Problem wäre) NICHT geeignet. Für DEIN Ansinnen. Weil du viel zu wenig Ahnung von der Materie hast. Weil ein viel zu kompliziert für Anfänger ist. Befasse dich bitte zunächst mit einfacheren uC und Protokollen. Es gibt in jedem Baumarkt Funksteuersysteme mit Schalter (Ein/Aus) oder Dimmung und entsprechende Empfangsmodule für die Lampen dazu. Ich denke diese Dinge zu verwenden ist einfacher. Gruss
aber wenn ein Controller so ziemlich alle Nachrichten aufnehmen soll dann komm ich da doch mit den Filter in schwierigkeiten. also ich bin noch nicht ganz durchgestiegen was das mit den Masken aufsich hat, aber liege ich richtig wenn ich denke das mit damit dann ganze ID-Bereiche abdecken kann? das der Controller quasi dann zum Beispiel im ID-bereich von 0 bis 16 alle nachrichten aufnimmt und verarbeitet?
Ach, Erich (warum muss ich gerade an Honecker denken? Der hat auch nie verstanden, wie es wirklich läuft) Ist doch ein perfektes Gebiet, sich mit CAN vertraut zu machen. Kurzfristig leben wir von Sachen, die wir einfach kaufen. Langfristig von den Sachen, die wir verstehen. Und jeder sollte min. 1 Gebiet haben, dass er versteht. Also, ran an den CAN!
Christoph Herzog schrieb: > abdecken kann? das der Controller quasi dann zum Beispiel im ID-bereich > von 0 bis 16 alle nachrichten aufnimmt und verarbeitet? ja das kann man mit der MASK machen, die sagt einfach nur welche bits zum vergleich mit der definierten CANID "genutzt" bzw. "ignoriert" werden sollen. am einfachste für dich wird es sein eine wildcard-mask zu verwenden (d.h. ALLE nachrichten werden empfangen) und die auswertung der CANIDs machst du dann über ein switch statement...für den anfang ist es das beste, und da es bei dir nicht auf performance, lowcost oder sonstwas ankommt ist es auch vertretbar... im automobil/industriebereich sieht das tlw. ganz anderst aus.. @Frank CAN Open wäre schon das richtige für die Aufgabe, nur der thread ersteller wird damit erst recht total überfordert sein...
Erich schrieb: > Hallo Christoph, > sorry daß ich das jetzt so schreiben muss: > CANBUS ist für dein Ansinnen (egal ob 1- oder x-Raum, und ob 15 oder > 1500 Lampen was auch kein Problem wäre) NICHT geeignet. > > Für DEIN Ansinnen. > Weil du viel zu wenig Ahnung von der Materie hast. > Weil ein viel zu kompliziert für Anfänger ist. > > Befasse dich bitte zunächst mit einfacheren uC und Protokollen. > > Es gibt in jedem Baumarkt Funksteuersysteme mit Schalter (Ein/Aus) oder > Dimmung und entsprechende Empfangsmodule für die Lampen dazu. > Ich denke diese Dinge zu verwenden ist einfacher. > > Gruss ich gebe dir vollkommen recht... ich hab davon noch keine Ahnung... aber ich mach das ganze nicht um das licht dann von woanders ausmachen zu können... das würde sicher einfacher gehen... viel mehr geht es mir um das erlernen der materie... als ich mich gestern so belesen hab musste ich ein wenig schmulzen als ich in einem Forum einen Beitrag von 2009 gelesen habe in dem Jemand ein Bus aufgebaut hat wo man sofort sehen konnte das das totaler Blödsinn ist und nicht geht... der Kerl hat sich ewig gewundert warums nicht klappt obwohls aus meiner Sicht sofort eindeutig war... Heute hat er ne eigene HP zu genau dem Thema und noch vielem mehr.Hilft anderen in verschiedenen Foren. Man lernt halt nur durch Fehler und wenn man sich ewig damit beschäftigt. ich möcht zwar keine HP drüber schreiben... aber wenn ich deinen Rat jetzt befolge lern ichs nie... Ich kann mich nur für manch blöde Fragen entschuldigen.
Danke Dir H.Joachim Seifert für deinen Meinungsbeitrag. Ich bin bei einem Zulieferer für "Automotive" tätig, und wir verwenden CAN mit 11- und 29-Bit gemischt und allerhand Schnickschnack. Wir haben auch paar Meßgeräte dazu wie Scope mit CAN-Dekodierung und was man eben so braucht. Paar preiswerte Dinge von Vector Informatik etc. Aber eine Lampensteuerung daheim würde ich damit nicht bauen. Gruss
angesichts der Tatsache das meine eigentliche Fragen beantwortet ist, ists wohl nicht so schlimm wenn der Threat das Thema verliert. darum dazu: nein Also die Lampensteuerung ist einfach und übersichtlich... natürlich soll es nicht nur bei den Lampen bleiben... aber einerseits wird hier gesagt das CAN-BUS für mich wohl zu schwierig ist... anderer seits soll ichs nicht damit machen weil der CANBUS zu aufwendig ist oder wie auch immer.. das passt so nicht Leute... wenn ich morgen mit der Idee ankommen die Bremsen von einem Fahrzeug damit zu steuern weil der Canbus dafür entwickelt wurde dann schreien auch wieder alle rum... es heißt doch immer man soll klein Anfangen oder? und wenn man ( jetzt stell ich mich einfach mal als jugend dar und den ein oder anderen hier als Erfahrenen Erwachsenen) der Jugned sagt sie soll die finger von allem lassen und bloß nichts neues Probieren ... dann brauch sich auch niemand wundern wenn wir nichts können...
Sag ich doch. Alle Sachen demystifizieren sich, wen man sich damit beschäftigt. Alle kochen nur mit Wasser. Erstmal steht man staunend wie ein Ochs vorm Tor, irgendwann macht es klick. Dann versteht man, was dahinter steckt und kann es nutzen. Und selbst, wenn du es nie wieder brauchst - es bleibt das Erlebnis, es geschafft zu haben. Und das macht Spass.
Hallo, das Thema CAN-Bus als Hausautomatisierung kommt immer wieder vor, auch hier, allerdings häufiger in dem Unterforum "Hausbus". Dort ist eine Vielzahl unterschiedlicher Eigenentwicklungen in unterschiedlichen Reifegraden zu finden, die sicherlich nicht alle von CAN-Profis begonnen wurden. Wenn Erich also meint, dass er keine CAN-Hausautomatisierung bauen würde sollte man dies als nicht repräsentative Einzelmeinung sehen. Wenn man bei so einer Eigenentwicklung allerdings nichts vorhandenes übernehmen will, stellt sich immer die Frage, wie die eizelnen Elemente eines solchen Busses zu adressieren sind. Dabei hat sich bei den verschiedenen Systemen als vorteilhaft herausgestellt, wenn eine Nachricht sowohl Quell- als auch Zieladresse enthalten kann, da dann alle Möglichkeiten der Selektion gegeben sind. So kann dann z.B. Lampe 1 auf alle Nachrichten hören, die von Schalter 1, Schalter 2, ... an sie gesendet werden (sie selektiert das Ziel "Lampe 1"). Umgekehrt kann sie aber auch so konfiguriert werden, dass sie gezielt Nachrichten von Schalter 17 ignoriert, selbst wenn dieser "Lampe 1 an" senden sollte (kann z.B. zum "Überstimmen" von Bewegungsmeldern sinnvoll sein). Nur die Quelle anzugeben hat den Nachteil, dass die Ziele nicht selektieren können (dazu gibt es in der Regel zu viele Quellen). Nur das Ziel anzugeben ist besser, verhindert aber weitere Bearbeitung (z.B. das gezielte Beantworten von Anfragen). Beim CAN bietet es sich an, sowohl Quelle als auch Ziel in dem Identifier zu kodieren, da dann über die Masken leicht eine Selektion der Nachrichten in Hardware durchgeführt werden kann. Auch bleiben so die 8 Byte der Nachrichtenlänge vollständig für die Befehle/Stellwerte zur Verfügung. Dabei bietet sich dann auf Grund der Länge der Extended ID an, da man sonst auf 2*32 Teilnehmer begrenzt wäre (2*5 Bit, eines bleibt übrig). Ob man nun jedem einzelnen Element eine eigene ID gibt und damit einen Hardware-CAN-Knoten auf verschiedene IDs "hören" lässt, wenn er mehrere Elemente, z.B. Lampen, schalten soll, oder ob man noch zusätzlich einen Element-Selektor in den Befehl einbaut (z.B. schalte Relais 3 des CAN-Knotens 14) bleibt einem dann noch überlassen - beides hat Vor- und Nachteile, so dass sich hier auch Mischformen anbieten. Meine Umsetzung dieser Grundideen kannst Du unter https://github.com/maveric00/HomeCANtrol/wiki/Protocol ansehen (allerdings in Englisch). Dort ist das Protokoll meines Heim-Bussystems beschrieben welches inzwischen seit 3 Jahren problemlos läuft und inzwischen etwa 50 Sensoren - Schalter, BWM, Lichtsensoren... - und 140 Aktoren - Licht, Rolläden, Steckdosen - umfasst. Eventuell kannst Du ja hier eine Inspiration bekommen. Schöne Grüße, Martin
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.