ESP8266 KNX mit ETS

[metaneutrons]

Moin Waldemar, sorry...ich wollte nicht so ungestüm sein.

Meine Vorschläge hätten jedenfalls keine Auswirkungen auf die aktuelle API. Die größte (mögliche) Änderung die ich im Moment sehe, wäre der Wegfall der Auto-Instanziierung des knx-Objekts. Da geht ja aber die Tendenz dazu, es einfach wie gehabt zu belassen.

Herzliche Grüße, Fabian

[mumpf]

Hallo Fabian,

bitte nicht falsch verstehen, ich freue mich, dass es hier so dynamisch weiter geht. Ich musste gestern nur grinsen, weil ich mit "restartDevice" das erste mal eine Änderung mache, die durch mehrere Schichten im Stack geht und immer, wenn ich das Gefühl habe, jetzt bin ich in den letzten Zügen mit den Tests ist wieder eine neue Version da, die dann eben wieder sorgfältiges Merge und einige Tests erfordert. Ich will ja keinen Unsinn in den Pull-Request packen.

Aber wie gesagt, weiter so, ich bin ja sehr an ESP32 mit TP interessiert, wenn auch eher aus Neugier und perspektivisch auch am Raspi (also Linux) mit TP als Test-Engine. Insofern nur weiter so, lass Dich nicht von meiner "Langsamkeit" ausbremsen .

Ich schau mal, dass ich heute mal wieder auf den neusten Stand komme...

Gruß, Waldemar

[dreamy1]

Sorry für die blöde Frage, aber sind ESP&Co nicht zu hungrig, um diese direkt am KNX zu betreiben? Dann braucht man Bus+Strom am Einsatzort, also macht Wifi dann eigentlich keinen Sinn mehr bzw. der Einsatz eines ESP...oder übersehe ich da was?

[mumpf]

Hi Stefan,

die Frage ist nicht blöd... und ich bin wahrscheinlich auch der falsche, sie zu beantworten, aber meine Sicht der Dinge ist:

• Die meisten Sachen werde ich wohl mit der SAMD-Platform machen (da geht die Versorgung über TP prima)
• Da ich u.A. derzeit eine Logikengine haben will (auf Mikrocontroller-Basis, ohne Bootzeit), brauche ich viel RAM. Da wäre der ESP32 interessant, dann eben mit TP und Stromversorgung. An sich braucht der ohne Wifi angeblich < 10mA, aber beim "poweron" ist Wifi immer an, dann startet der nicht nur mit Busversorgung. Aber ich bin nicht so der Hardware-Mensch...
• Die Alternative wäre Wifi + Stromversorgung an irgendeiner Stelle, wo man keinen Bus hat. Könnte ja mal in der Zukunft interessant werden, wenn doch die Busleitung vergessen wurde.

Der Vorteil, mit einem Stack alle Platformen abzudecken und dann auch noch die ETS-Parametrisierbarkeit zu haben, ist für mich ausschlaggebend. Dann kann man sich ja die Zielplattform aussuchen...

Gruß, Waldemar

[dreamy1]

Mit einem Stack alle Plattformen abzudecken, macht natürlich Sinn. Mal schauen, ich bin gerade auch am Testen neuer Hardware und Beschaltungen und ich bin mir recht sicher, dass ich einen halbwegs potenten Prozessor mitsamt Wifi an den TP bekomme - ohne zusätzliche Stromversorgung. Das eröffnet dann ganz neue Möglichkeiten. Vielleicht gibt es da auch Synergien, die wir nutzen können.

[thesing]

metaneutrons: Mach ruhig. Bei der Gelegenheit könntest du noch getter/setter für das _knxSerial hinzufügen. Dann kann man das im Sketch leicht ändern. Das hatte ich vergessen.

mumpf Die aktuellen Änderungen dürften doch ganz andere Dateien betreffen, oder?

VG Thomas

[metaneutrons]

@dreamy1: Die Frage zum Stromhunger des ESP ist in der Tat nicht doof. Ich nutze den ESP32 auf einem Olimex Board mit Ethernet-Schnittstelle tatsächlich in meinem Serverschrank, um diverse Dinge an den Bus anzubinden (DIY Klingel mit RFID Leser, Anbindung meiner Rauchmelder (siehe https://github.com/metaneutrons/girf), etwas Logik und eventuell Zeitschaltungen). Da ist der Stromverbrauch natürlich zweitrangig.

Ich habe bisher noch keine Geräte produktiv auf dem Bus, die ich von dort speise. Dafür würde ich vermutlich die Teensys nehmen.

Gibt's eigentlich eine smarte TPUART-Lösung? Ich habe gerade meine Siemens BCU rausgesucht - ganz schön klobig!

Herzliche Grüße, Fabian

[dreamy1]

Hallo Fabian,

die reine Platine der Siemens BCU ist recht klein, der Rest ist Gehäuse und Tragring. Und genau da sehe ich den Vorteil, denn alles was man an der Wand befestigen möchte (Taster, Sensor, Display etc.) ist dann bereits mechanisch vorbereitet. Und es gibt halt einen tausendfach bewährten und zertifizierten BA, der in der UP-Dose keine Bauchschmerzen verursacht.

Aktuell kann ich die von mir entwickelten Geräte per Bluetooth-Adapter wireless programmieren, das wird zukünftig aber deutlich smarter. Ich will nicht zuviel verraten, aber so wie es aktuell aussieht, geht das zukünftig direkt aus der Arduino IDE heraus ohne weitere Geräte. Da bin ich noch am Testen.

[Masifi]

Gibt's eigentlich eine smarte TPUART-Lösung? Ich habe gerade meine Siemens BCU rausgesucht - ganz schön klobig!

Es gibt noch die MicroBCU: https://knx-user-forum.de/forum/proj...nx-transceiver
Läuft soweit Problemlos bei mir und vielen anderen und man bekommt hier zwei unabhängige Spannungen. Einmal direkt 3,3V (~80mA) und zusätzlich noch 5V (~80mA), wobei man die 5V auch durch umbestücken auf Werte zwischen 1,2V - 19V bringen kann.
Natürlich ist sie nicht zertifiziert, aber wenn man an eine Siemens 5V BCU einen Schaltregler aus der Bucht bestückt, dann bin ich mir ziemlich sicher, dass sich dein Gesamtsystem nicht mehr "zertifiziert" verhält -> ein Risiko hast du beim "Basteln" immer :-( :-)

die reine Platine der Siemens BCU ist recht klein, der Rest ist Gehäuse und Tragring. Und genau da sehe ich den Vorteil, denn alles was man an der Wand befestigen möchte (Taster, Sensor, Display etc.) ist dann bereits mechanisch vorbereitet.

Da stimme ich dir zu, aber der Berker Sensoreinsatz erfüllt das auch, zusätzlich hat man hier aber noch den Vorteil, dass man mehr Bauraum nutzen kann.
Ich konnte hier damit deutlich mehr unterbringen und zusätzlich noch einfach aufsteckbare Platinen verwenden
https://knx-user-forum.de/forum/proj...-sensoreinsatz

[dreamy1]

Kann ja jeder machen wie er will - ich will direkt *in* der UP-Dose halt keine DIY-Basteleien, schon gar nicht ohne schützendes und selbstverlöschendes Gehäuse in einem thermisch in den meisten Fällen quasi abgeschlossenen Hohlraum. Der angesprochene Stepdown sitzt bei mir aus gutem Grund nicht in der UP-Dose und ist zudem über den TPUART mit seinen integrierten Schutzmechanismen abgesichert. Den kannst Du auch problemlos einfach kurzschließen, da passiert durch die Strombegrenzung des TPUART einfach rein gar nix.
Mit zertifiziert meine ich, dass bei mir alle Basteleien erst "hinter" dem direkt am Bus befindlichen Gerät (in dem Fall der Siemens BA) stattfinden. Egal was da seitens DIY passiert, am Bus direkt physikalisch angeschlossene Geräte wie der Siemens TPUART sind alle KNX-zertifiziert und "abgenommen". Es wird lediglich die nach außen "freigegebene" physikalische Anwenderschnittstelle benutzt.

Ein selbst designter BA kann natürlich funktionieren, es reicht aber leider auch ein nicht ganz perfekt designtes Bauteil (Toleranzen, Alterung!) oder schlecht oder mit dem falschen Lot verlötetes Bauteil und die empfindlichen Signalverläufe der Bustelegramme werden verschliffen oder ähnliches oder ein Kondensator geht nach drei Jahren wegen der komplexen Ripplestrombelastung hoch...von EMV ganz zu schweigen (beim Siemens TPUART gibt's extra Abschirmbleche im Inneren)...das hängt wiederum natürlich alles von der Kompetenz des Hardwaredesigners ab, solche Dinge beim Design allumfänglich zu berücksichtigen.

Den Siemens BA bekommt man übrigens mittlerweile unter 20€...

[Masifi]

Wir lassen das Thema hier lieber :-) passt nicht ganz in den Thread

(sorry aber so stehen lassen kann ich das nicht :-) und ärgern will ich niemanden damit, aber die Aussagen sind sehr überspitzt und sehrrr theoretisch einfach gesagt. daher nehmt es mir bite nicht übel :-)
ja ich gebe dir mit dem Gehäuse etwas recht, das macht es sicherer, aber da wo ich herkomme sagt man, dass es nur zu einem Brand kommen kann, wenn mindestens 10-Watt an Leistung bereit gestellt werden können. Bei weniger Leistung kann es vielleicht schmoren, aber nicht "brennen". Bei kleinen KNX Netzteilen 320mA bist du im Leerlauf schon unter 10W, bei den Größeren bist zu zwar im Leerlauf drüber, da aber weitere KNX Teilnehmer das Netzteil zusätzlich mitbelasten bist du auch in diesen Fällen in der Regel unter 10W. Aber ja es besteht die Möglichkeit bei einer ungünstigen Auslegung, daher gebe ich dir auch recht. Ein Grund, wenn man Angst vor "Bränden" hat, dass es vielleicht besser ist, nicht das "größte" KNX Netzteil zu nutzen, wenn man es gar nicht braucht. :-) und ja die Netzteile können im Peak noch mehr, aber der Peak ist meiner Meinung nach deutlich kürzer als die Zeit die es braucht, das PCB Material so zu erhitzen, dass es zu einer "Flamme" kommt.
Der DC/DC Regler in der MicroBCU ist genauso abgesichert wie die Siemens BCU. Diesen kann man Kurzschließen wie man will und die thermische Abschaltung habe ich beim Basteln damit auch schon das ein oder andere mal in ihrer Funktion bestätigt gesehen. Das ist eine interne Funktion des Bausteins NCN51XX, die nicht durch unsachgemäße Anwendung gestört werden darf, das muss der Hersteller garantieren.
Der KNX Bus läuft mit 30V und 6V Pegeln und einer Baudrate 9600Baud/s (das ist sooooo langsam, wie sonst schafft man es Bus Längen von etlichen hundert Metern zu erreichen) Das ist unglaublich robust und das muss es auch sein und das auch gegen alle möglichen Störungen von Außen. KNX Leitungen dürfen neben 230V Leitungen verlegt werden. Überlegt doch mal was es hier an übersprechenden Störungen in einem Kabelkanal gibt. Vorallem wenn wein 230V Hochstromverbraucher ein und ausgeschalten wird. Solche Störungen = "verschleifen" vom Bus-Signal bekommst du mit einer falschen Toleranz und mit dem falschen Lötzinn nie und nimmer hin. Und eine Alterung haben alle Bauteile auch die in der Siemens BCU. He schlechtes Lötzinn !? Das Lötzinn was in euren "billig" in China bestückten KNX-Device verwendet wurde, ist um welten schlechter als das was man hier im Laden bekommt. Ein halbwegs verbünftige Lötstelle kann man mit dem blosen Auge erkennen. Dazu muss die Lötstelle in Devicen die kaum Temperaturwechsel sehen, auch nicht viel aushalten. "schlechte" Lötstellen entstehen in der Regel nur, wenn sich das Bauteil bei Wärme/Kälte anders ausdehnt als die PCB. Ich gehe mal davon aus, dass sich eure Zimmertemperatur über das Jahr nur um wenige Grad ändert -> wenig Druck auf die Lötstelle = Lötstelle hält länger. Wenn Ihr device im Außenbereich einsetzt, dann spielt das wieder eine Rolle klar. Aber auch die MicroBCU wurde maschinel in Deutschland bestückt -> "deutsche Qualität" :-)
Des weiteren gibt der Hersteller des NCN51XX die Bauteile + Toleranzen genau an. Hohe Rippleströme müssen bei ELKOs beachtet werden keine Frage, aber woher sollen diese "hohen" Ripple kommen !? Aus dem KNX-Bus sollten laut spec mur max 10mA gezogen werden, daran sollte man sich auch halten. Aber auch hier macht der Hersteller eine genau Aussage im Datenblatt, der ESR des ELKOs soll <2Ohm sein. Ich habe mal bei Reichelt schnell nach dem billigsten SMD Elko geschaut und dieser hat bei 35V DC rating einen ESR von 0,26ohm, also einen 8fach kleineren ESR als gefordert. Ripplestrom + ESR zusammen machen den ELKOs Probleme in der Verlustleistung = Alterung
Viel wichtiger bei ELKOs ist eigentlich das Temperaturverhalten, vorallem bei hohen Temperaturen (= Austrocknung) aber bei Raumtemperatur ist auch das eher unkritisch.
Dann bleibt ganz allein noch das EMV-Verhalten, aber da ist jede Bastelei ein Wagnis :-) Die Siemens BCU ist da sicher geprüft, aber nur nach einer Spec. Wenn dein DC/DC Regler Leitungsgebunden zurück in die BCU stört, dann weis keiner ohne eine Messung, wie die Siemens BCU damit umgeht. Also auch hier ist das für mich nur eine "sich selber eingeredete Sicherheit". In der EMV muss man sich immer das Gesamtsystem anschauen und nicht nur eine Einzelkomponete. Der DC/DC im NCN51XX macht zumindest mal "slope control" passt seine Schaltflanken zumindest mal an (damit wird das EMV verhalten verbessert), ob das alle billigen DC/DC Regler können die man für wenige Euros bekommt, möchte ich bezweifeln.
Ich habe mal einen Barthelme KNX LED Dimmer aufgemacht und war überrascht wie einfach er aufgebaut ist. Ich habe alle Bauteile geprüft und es sind 1:1 die gleichen wie im KNX Datasheet gefordert wurden. Von EMV Schutzbeauteilen habe ich nichts gesehen.
Dreamy, ich gebe dir in allem Recht, man muss sich die Punkte anschauen, aber wenn man das mal genau tut, also im Datenblatt nicht nur die "marketing" erste Seite liest (die jeder gute Ingenieur direkt übergeht), dann merkt man sehr schnell, dass das Riskio gering wird. Eugenius hat in seiner MicroBCU diese Punkte sicher auch beachtet, aber klar, jeder trägt das Risiko selber wenn er DIY einsetzt. Falls du Lust hast wieder weiter zu diskutieren, dann machen wir das wieder im PN :-)
Und auch klar, wer nur wenig Ahnung von Elektronik hat, der sollte sich genau überlegen was er tut !!! )

[dreamy1]

Ja, natürlich ist das etwas überspitzt formuliert. Es sind ja in der Regel auch nicht die normalen Betriebsbedingungen, die Probleme verursachen. Beim Design von Hardware gibt es ja auch noch andere Herausforderungen wie Leiterbahnführung und tausend andere Dinge :-) Ich sehe außer der kompakteren Bauweise des MI halt nicht wirklich einen Vorteil, sondern eher mehr Nachteile.

Ist aber auch egal, hast Recht....wir schweifen ab...deshalb auch gerne von mir back to topic :-)

[Bernator]

Super die Änderungen gefallen mir, weiter so

Den Siemens BA bekommt man übrigens mittlerweile unter 20€...

wo denn?

[dreamy1]

Also bei mir funktioniert Google:

https://www.steckplatz.de/1-Stk-Busa...SABEgLrNvD_BwE

[Nanosonde]

Guten Morgen.

Ist das Python Modul knxPython im GIT-Repo eigentlich funktional?
Gibt es irgendwelche Einschränkungen?
Gibt es irgendwo Beispiele zur Benutzung?