selfbus.org

Zumindest für den Offset ist das eigentliche Problem die unterschiedliche Interpretation des Datentyps char durch den LPC und den ARM Compiler. Das ist aber (ein vom Hersteller) so gewünschtes Verhalten. Im Falle des RM hat man das offensichtlich nicht bedacht. Die Lösung ist dem Compiler die entsprechende Option mitzugeben (auch das ist vom Hersteller so vorgesehen) oder den Programmcode entsprechend anzupassen.
Um die Seriennummer müssen wir uns noch kümmern, der Rest funzt aber erstmal. Von daher werde ich den Lötkolben bald wieder anwerfen und weitere ARM Module bauen - für mich spricht erstmal nix dagegen

Ansonsten glaube ich hat es das Projekt selfbus in Zeiten von Arduino und Tasmota, aber auch professionellen und vergleichsweise günstigen Herstellern wie MDT, ziemlich schwer. Das Einsparpotential ist in den letzten Jahren deutlich gesunken. Demgegenüber steht einiges an erforderlicher Einarbeitungszeit und Elektronik- bzw. Programmier-Know-How.
Ich denke es wird für einige wenige Spezialanwendungen die nicht an jeder Ecke zu bekommen sind, Sinn machen. So z.B. der Rauchmelder oder eine Torsteuerung oder Ähnliches...

Viele Grüße,
Klayman

Vergeßt aber nicht den Spaß und die Erfolgserlebnisse die man hat, wenn es dann funktioniert!
Gruß
Hans

klayman hat geschrieben: Ansonsten glaube ich hat es das Projekt selfbus in Zeiten von Arduino und Tasmota, aber auch professionellen und vergleichsweise günstigen Herstellern wie MDT, ziemlich schwer. Das Einsparpotential ist in den letzten Jahren deutlich gesunken. Demgegenüber steht einiges an erforderlicher Einarbeitungszeit und Elektronik- bzw. Programmier-Know-How.

Da muss ich dir in weiten Teilen Recht geben. Was selfbus aber vielen anderen Lösungen voraus hat, ist die Möglichkeit, eine "echte" vd zu verwenden. Das ist aus meiner Sicht ein großer Pluspunkt.

Was ich mich allerdings auch frage, warum keiner beides verbinden mag, so lange es einen Vorteil bringt.
In meiner Wunschvorstellung würde ich den Teil mit der Busankopplung als fertiges Modul kaufen (oder alternativ zum Selbstbau), das geht mittlerweile <20€. Die Applikation mit einem arduinoartigen µC bestreiten, die gibt es mittlerweile für ca. 2€ als Platinchen und sich sonst ganz auf die Applikation konzentrieren. Würde theoretisch Geräte mit ca. 30€ möglich machen.

KONNEKTING schlägt zwar von der Hardware diese Richtung ein, aber die fehlende vd und zusätzliche "Programmiersoftware" ist natürlich ein großes Manko. Zudem gibt es dort auch keine nachbaubaren Projekte. Platinen- und Bautleilbeschaffung ist auch zu großen Teilen unklar. Und am Ende "rechnen" tut sich das dann wohl auch nur für Spezialanwendungen.

Just my 2ct.

Die Controller bei Selfbus gehen ja ein Stück weit in die Richtung einer universellen Busanbindung mit applikationsspezifischen Erweiterungsplatinen. Vielleicht würde es helfen universalplatinen mit ein paar I/Os und PWM oder vielleicht noch analog I/Os oder SPI und was es sonst so gibt zu entwickeln. Im Prinzip sowas wie die NodeMCU Entwicklungsboards mit ESP8266, nur eben mit KNX Busanbindung. Die Elektronik ist für viele ein wahrscheinlich noch größeres Hindernis als das Programmieren. Zumal man Software leichter teilen kann.
Mir würden für mein eigenes Haus aber auch nur sehr wenige Anwendungsfälle einfallen:
- Garagentor
- BME680 als VOC-Sensor
- Modbus für die Heizung
- Rauchmelder

Kennst Du eigentlich das Passwort der vd1-Dateien?

Viele Grüße,
Klayman

Hi Klayman,

klayman hat geschrieben:uuuh, ich glaub ich hab's gefunden

da ja von Entwicklerseite scheinbar keine Antworten mehr zu erwarten sind: kannst Du mir vielleicht irgendwie ein passendes HEX-File zukommen lassen? Damit könnte ich zumindest schonmal sinnvolle Temperaturen messen.

Vielen Dank!

Servus zusammen,

ich geb dann auch mal meinen Senf dazu:

Ja, es mag durchaus richtig sein, dass insb. im Vergleich zu MDT das Einsparpotenzial nicht mehr so wahnsinnig groß ist. Wenn ich mir jetzt aber über lege, dass ich insgesamt etwa 35 ARM Eingangsmodule einbauen werde, 21 Rollos und diverse Steckdosen schalten möchte, 16 Heizventile ansteuern will, etc. etc. dann kommt doch ein Sümmchen dabei raus, das ich mit Eigenbau besser verargumentieren kann als mit Kaufgeräten.
Sich in Selfbus einarbeiten rein aus monetären Gründen fände ich etwas krass. Ohne Leidenschaft für die Technik an sich wird man es schwer haben.
Wie ihr ja selbst festgestellt habt, gäbe es ja außerdem noch einige Ideen, die man einfließen lassen kann.

Einfließen lassen heißt aber auch: selbst coden, selbst basteln und entwerfen. Es gibt einige die in der Vergangenheit viel fürs Projekt gemacht haben, jetzt aber einfach nicht mehr können oder wollen. Vielleicht auch nur temporär, wer weiß? Dass die "alten" Entwickler aktuell nicht antworten kann man keinem verübeln - vielleicht bekommen sie's auch gerade nur nicht mit. Ich selber hatte auch nicht vor, so viel selbst auf meiner Baustelle zu machen - da fällt Selfbus mal ganz schnell hinten runter, wenn der Trockenbauer vielleicht schon die Decke zu macht, noch bevor alle Kabel drin sind.

Es ist ein offenes Projekt. Wenn also jemandem eine Lösung zu einem Problem einfällt - postet es, macht einen Pull Request.

Weil mal ganz ehrlich: Tontechniker hat schon recht. Es ist schon echt cool, wenn das Zeug tut, wie es soll. Und wenn man es selbst gebaut hat und sich in die Sache rein gefuchst hat, kann es am Ende auch noch reparieren, wenn es mal in 10 Jahren abrauchen sollte.
Ich hab jedenfalls Bauteile, dass ich gefühlt noch 3 mal bauen könnte mit KNX Vollausstattung.

Beste Grüße
Christian

Hallo,

um mal wieder zurück zum Thema zu kommen, damit der Compiler char als signed betrachtet.
Könntet ihr mal bitte probieren:

1. Project settings -> C/C++ General -> Paths and Symbols -> Symbols -> Languages
   • GNU C -> __CHAR_UNSIGNED__ auf 0 setzen
   • GNU C++ -> __CHAR_UNSIGNED__ auf 0 setzen
2. oder fügt unter Project settings -> C/C++ Build -> Settings -> Tool Settings
   • -> MCU C Compiler -> Miscellaneous -> Other flags:

     Code: Alles auswählen

     ... -fsigned-char

   • -> MCU C++ Compiler -> Miscellaneous -> Other flags:

     Code: Alles auswählen

     ... -fsigned-char

   hinzu

Evtl. müsst ihr das sowohl für die slib als auch das jeweilige Modul (z.B. Rauchmelder) einstellen.

Gruß

Hallo,

ich habe es mittlerweile selber ausprobiert. Option 2 funktioniert, bitte nicht vergessen dies für alle Projekte in der IDE (slib, Rauchmelder, etc.) einzustellen. Vielleicht sollte man dies für die einzelne Projekte auf github in den .cproject Datein voreinstellen?

Gruß

Hallo,

anbei je ein patch für die Repositories um den char type standardmäßig als signed zu interpretieren.

• software-arm-lib
• software-arm-incubation

EDIT** Für den patch bitte die Datei aus meinem folgenden Beitrag nehmen, da der ursprüngliche hier verlinkte patch fehlerbehaftet war **EDIT

Könnte diese bitte jemand mit Berechtigung anwenden und auf Github hochladen?

Gruß

Marinux hat geschrieben:Könnte diese bitte jemand mit Berechtigung anwenden und auf Github hochladen?

Bitte nicht in der Form, der Patch braucht erst einen Patch: es wird ueberall das Flag "data-sections" durch "data-section" ersetzt wodurch nix mehr kompiliert!

Im uebrigen wird in der ETS noch immer die falsche Applikations-Version angezeigt (18 anstatt 0x18 bzw 18 statt 24), er taucht nicht als "Robert Bosch Rauchmelder" sondern als "Robert Bosch 03F2" auf und vermutlich wird noch immer eine "0" als Seriennummer ausgegeben (was ich nun aber nicht ausprobiert habe).
Alles in allem hat die ARM-Variante scheinbar noch ein wenig Aufholbedarf, die LPC-Versionen hingegen funktionieren sauber und komplett so wie es zu erwarten ist...

gruesse :: Michael