Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Die Codestelle oben behandelt nur das TX timeout, also wenn der TPUart nicht mit einem etnsprechenden Echo auf ein Frame vom Stack reagiert wird hier der Schicht darüber signalisiert das beim Senden was schief ging, ich denke also nicht das dies hier dein Problem ist. Aber es stimmt das alle ankommenden Frames in ein CEMI Frame beginnend mit den beiden Konstanten 0x29 0x00 gepackt werden, warum das so ist müsste Thomas wissen denn das hat er bei der alten Variante auch so gemacht, hab ich nur übernommen.
Das CEMI Frame scheint nur ein Container für höhere Schichten zu sein, der TPUart kennt das nicht un empfängt/sendet nur blanke Frames ohne CEMI Header.
Von deinem oben genannten CEMI Frame:
wird also nur der rot markierte Teil tatsächlich auf den Bus gesendet, ich denke die Gegenstelle wird dann wieder einen entsprechenden CEMI Header dazubauen?
Das dachte ich beim Namen der Methode auch. Aber ich habe ein Telegramm von 1.0.6 an 1.0.115 gesendet. Warum wird genau dieses Telegramm in einer Empfangs-Methode zusammengebaut? Da würde ich ja Telegramme erwarten, die entweder eine GA als Ziel haben oder 1.0.6 als Ziel und nicht als Quelle. Deswegen kam ich drauf, dass es da passiert. Das war zumindest mein Gedankengang...
Vielleicht weiß ja Bernator mehr und kann einen Tipp geben.
die stelle die du gefunden hast hat nichts mit deinem Problem zu tun. Die gefundene Stelle ist für den Empfang da. Die beiden Bytes sind die ersten Bytes von einem Cemi-Frame vom Typ L-Data.ind mit (0x29) mit 0 Bytes an "Additional Information" (Siehe 3/6/3)
Es aber wirklich das erste Byte das Problem zu sein. Bit 2+3 kann du durch dir Priorität beeinflussen. 0+1 sollten eigentlich immer 0 sein. Hab auch die Schnelle nicht gefunden, wo die gesetzt werden. Probiert mal bei CemiFrame::fillTelegramTP(uint8_t* data) zu schauen ob da schon data[0] falsch gefüllt wird. Wenn ja muss es schon ein Problem beim Erstellen des CemiFrames geben.(Evtl. nicht initialisierter Speicher?). Ich glaube nicht, das es ein Problem vom tp-uart-Datalinklayer ist. Solltest du also unter Linux debuggen können.
Edit: Ok. Falsch. Unter Linux wird ja IP genutzt. Da müssen die Bits wahrscheinlich nicht unbedingt 0 sein.
Bernator: Ich glaube, ich habe einen Fehler in Deiner Implementierung der SAMD asyc Kommunikation gefunden... Es geht um das T_Connect Kommando. Du schickst
Die roten Bytes sind das Problem (denke ich), die grünen sind OK, da die ETS ja ne andere PA hat als der SAMD. Und das orangene Byte ist wohl eher ne Prüfsumme, die Du ausgibst und das man in der ETS nicht sieht. Den selben Unterschied sieht man auch beim T_Disconnect, Du sendest
Ich habe auch im Coding folgendes gefunden (in tpuart_data_link_layer.cpp)
Code:
if (_waitConfirm) {
if (millis() - _waitConfirmStartTime > CONFIRM_TIMEOUT) {
println("L_DATA_CON not received within expected time");
uint8_t cemiBuffer[MAX_KNX_TELEGRAM_SIZE];
[COLOR=#FF0000] cemiBuffer[0] = 0x29;
cemiBuffer[1] = 0;[/COLOR]
memcpy((cemiBuffer + 2), _sendBuffer, _sendBufferLength);
dataConBytesReceived(cemiBuffer, _sendBufferLength + 2, false);
_waitConfirm = false;
delete[] _sendBuffer;
_sendBuffer = 0;
_sendBufferLength = 0;
if (_loopState == RX_WAIT_DATA_CON)
_loopState = IDLE;
}
}
Da weist Du die beiden Werte konstant zu. Das scheint die Problemstelle zu sein.
Ich muss aber sagen, dass das alles reine Vermutung meinerseits ist, ich habe mich mit vielen print-Ausgaben bis zu dieser Stelle vorgearbeitet und kann nicht behaupten, dass ich durch Dein Coding hier durchsteige. Deswegen habe ich auch keine Ahnung, wie ich das korrigieren soll. Ich bräuchte da irgendwie Hilfe...
Fakt ist, diese Protokolle erscheinen nicht im Gruppenmonitor der ETS, ich habe aber in meiner Anlage ein Gerät gefunden (BEG PM), dass auch auf dieses "falsche" T_Connect reagiert. Aber auch ein anderes Gerät (Temperatursensor), dass nicht darauf reagiert. Also denke ich, dass es so nicht korrekt ist... Wo müsste man reingreifen und woran erkennt man, ob ein 2E oder eine 29 im frame stehen muss?
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 :-)
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 !!! )
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€...
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
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.
@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!
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?
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: