Funktionen von OpenKNX Firmwares kombinieren

[traxanos]

Davon ab der fp wird auch für den up1 geben. Das müsstest du nicht selber machen .

[henfri]

-D OKNXHW_UP1_CONTROLLER2040
brauchst du auf jeden Fall

welches env hast du denn bisher genutzt? in github hat gar kein env das passende -D ..

Ich benutze zum Kompilieren dies
https://github.com/henfri/OAM-Finger...custom.ini#L81

Davon ab der fp wird auch für den up1 geben. Das müsstest du nicht selber machen .

Hm, bin schon dabei :-)

Gibt es dazu schon code?

Gruß,
Hendrik

[traxanos]

Sind ja nur paar defines. Und das gehört natürlich Innas Hauptrepo.

[henfri]

Hallo,

na klar ins Hauptrepo. Würde wohl einen PR erstellen, wenn es fertig ist.
Wenn jemand mit mehr Kompetenz schon dran ist, halte ich die Füße still. Falls nicht, kümmere ich mich drum, inkl. Test. Wenn mir noch jemand kurz sagt, wie ich die Variante kompiliert und aufgespielt bekomme. Der Code ist ja schon angepasst.
Aber es sind nicht nur Defines. RX und TX Pin sind hardgecoded in der fingerprint.cpp - siehe mein Commit.

Gruß,
Hendrik

[henfri]

Kann mir hier noch jemand helfen, wie ich meine Variante auf das Board bringe?

[Ing-Dom]

Ah, du verwendest das release-env. Das ist falsch, das lädt keine fw hoch, sondern erstelt das release-zip.


https://github.com/henfri/OAM-Finger...om.ini#L55-L61

[RP2040_custom_releases]
extends = RP2040_releases, RP2040_custom, custom
build_flags =
  ${RP2040_releases.build_flags}
  ${RP2040_custom.build_flags}
  ${custom.build_flags}

[env:debug_RP2040]
extends = RP2040_custom_develop
upload_protocol = mbed
;upload_port = D:\

[env:upload_JLINK_RP2040]
extends = RP2040_custom_develop, UPLOAD_JLINK​
[URL="https://github.com/henfri/OAM-FingerprintUP1/blob/67c0f42e47a0549d84aee5d66902dff623b11862/platformio.custom.ini#L55-L61"][/URL]

so wie die ini aufgebaut ist, unterstützt sie keine unterschiedlichen Hardware-Varianten für den develop-Fall. Das machen einige so (Waldemar, Andreas) - ich persönlich lege mir für jede HW noicht nur ein release, sondern auch ein debug env an. Egal - kuz gesagt:
du musst zum debuggen / entwicklen die Zeile aus dem [RP2040_custom_develop] ändern.

  -D BOARD_ABTOOLS_FINGERPRINT_V13

https://github.com/henfri/OAM-Finger...custom.ini#L42

du wählst dann [env:debug_RP2040] aus und drückst upload. dann sollte das klappen.

[henfri]

Vielen Dank. Das klappt!

Eins ist aber komisch: Bei den ersten zweimal Flashen ging das automatisch. VSCode hat den RP automatisch in den entsprechenden Modus gestartet.
Danach ging das nicht mehr, und ich musste das manuell machen.
Ich hab aber - natürlich - nix geändert.
Das eheste was mir einfällt wäre etwas physische Belastung an den Pins und eine schlechte Lötstelle. Oder gibt es noch andere mögliche Gründe?

Gruß,
Hendrik

[henfri]

Hallo,

ich komme nochmal hierauf zurück:

Das ist nun ein separates Projekt auf Basis eines REG1 ? Ich komme nicht mehr ganz mit...

Alternativ kannst du auch diese typischen Relaisplatinen nehmen

sowas 51WIhQCAUrL._AC_.jpg
und dir ein passende REG-Gehäuse drucken (gibts fertig). Die brauchen Hilfsspannung (zB 24V) und die Eingänge sind reine Signalpins die man mit GPIO schalten kann.

Welche Lasten / Spannungen willst du schalten? 16A / 230V ?

Aber ganz ehrlich - für 230V würde ich einen Aktor kaufen bzw. wenn es unbedingt ein OpenKNX Gerät sein muss dann nimm doch Andreas Aktor.

Für kleine Lasten und Spannungen ist aktuell ein 4fach Aktor im REG1 in Entwicklung.. da wirds noch dieses Jahr erste Beta-Geräte geben..

Hintergrund ist der, dass ich die Sauna Messen und regeln will.
Das Ganze wird - wenn man keine dezidierte Steuerung nutzt gerne so gemacht:
1) Schütz als Sicherheitsfunktion. Das Schütz wird größer dimensioniert als die für die Regelung genutzten Relais. Das Schütz wird über eine Schmelzsicherung und die Regelung (in Reihe) mit Spannung beaufschlagt.

Das fängt mehrere Fehlerfälle ab:
a) Ausfall der Regelung (alle Phasen an)
ODER
b) Klebende Kontakte bei den für die Regelung genutzten Relais
ODER
c) Überhitzung (warum auch immer)

2) 3 Relais für die Regelung der Temperatur (drei Phasen im Ofen), ebenfalls mit der durch die Schmelzsicherung geführten Spannung betrieben.

Das UP1-8xTH würde ich für die Erfassung der Messwerte (Temp und Türkontakt) sowie für die Regelung (Schwellwert mit Hysterese) nutzen.

Nach Waldemars und auch deinem Hinweis habe ich überlegt, einen MDT AKU zu nutzen. Aber dadurch würde ich eine der Redundanzen oben verlieren. Denn da habe ich zwei Relais hintereinander, die durch die Schmelzsicherung abgeschaltet werden.
Jetzt kann man aber schon - zu Recht vielleicht - sagen, dass diese zwei Stufen nicht nötig sind UND auch, dass sie nicht so viel bringen, weil das erste verklebte Relais ein "schlafender Fehler" sein wird.

Ein weiterer Vorteil, keinen Aktor, sondern 24V/Hutschinenrelais zu verwenden ist, dass sie billig zu ersetzen sind - schließlich wird hier oft und unter hoher Last geschaltet (aber auch hier weiß ich nicht, ob die Sorge berechtigt ist).

Vielleicht führt das hier zu weit.... Jedenfalls: Es hat o.g. Vorteil externe Relais zu verwenden. Das hat mich überlegen lassen die Aktorkanäle einzubauen und über eine Relais-Platine wie von dir oben gepostet die 24V (!) zu schalten.

Ich hätte aber noch zwei andere Usecases den Sen-UP-8xTH mit einem Aktor-Ausgang zu verbinden:
1) als Garagentorsteuerung
2) [mag skuril klingen] um dem GPIO eines ESP32 ein Signal zu geben. Das wäre eine "Arme Leute Lösung" für das hier:
https://knx-user-forum.de/forum/proj...rtlock-steuern (der ESP mach die Kommunikation zum Lock und Sonder-Funktionen wie Batteriestand, aber das kritische (Auf/Zu) läuft per Kabel. Zu mehr reichen -wie vielleicht bereits subtil von mir in diesem Thread angedeutet- meine Fähigkeiten nicht; zudem ist der ESP32 ja ohnehin nicht vom Bus aus zu versorgen.

Zum zweiten Usecase (ESP32: Das ist so direkt wohl erstmal nicht ratsam, da ich vermute, dass ich dann den GND vom Bus mit dem GND vom ESP (=5V Netzteil) verbinde, oder? Also ein Optokoppler dazwischen?

Gruß,
Hendrik

[Ing-Dom]

1) Schütz als Sicherheitsfunktion.

ich kann nur davon abraten OpenKNX Geräte oder FW für irgendwas zu verwenden was Sicherheitsrelevant ist.
Daher werde ich dazu auch nichts weiter sagen.

schließlich wird hier oft und unter hoher Last geschaltet (aber auch hier weiß ich nicht, ob die Sorge berechtigt ist).

Ohmsche Lasten sind eigentlich das dankbarste was man so schalten kann.
Heizelemente haben aber je nach Bauart im kalten Zustand einen sehr kleinen Widerstand => hoher Anlaufstrom. Weiß nicht ob das bei deinem Ofen der Fall ist (Datenblatt schauen).

Das hat mich überlegen lassen die Aktorkanäle einzubauen und über eine Relais-Platine wie von dir oben gepostet die 24V (!) zu schalten.

wie gesagt, es wird einen OpenKNX REG1 4fach Relais-Aktor gaben mit dem du die 24V von Schützen schalten könntest.. wenn das passend wäre.

Das UP1-8xTH würde ich für die Erfassung der Messwerte (Temp und Türkontakt) sowie für die Regelung (Schwellwert mit Hysterese) nutzen.

weil UP die passende Bauform ist, oder weil es aktuell kein REG1 dafür gibt?
Auch hier.. es wird bald ein REG1 Sensormodul geben, dass dafür verwendbar wäre, sofern du lieber ein Hutschienengerät verwenden willst.

Zum zweiten Usecase (ESP32: Das ist so direkt wohl erstmal nicht ratsam, da ich vermute, dass ich dann den GND vom Bus mit dem GND vom ESP (=5V Netzteil) verbinde, oder? Also ein Optokoppler dazwischen?

auf jeden Fall isolieren. Optokoppler, ReedRelais, PhotoMOS ....

[traxanos]

Oder gibt es noch andere mögliche Gründe?

normal immer dann wenn ein terminal auf ist und somit der com-port in nutzung ist.