Support Für SHT40

[MAKERWOLF]

Hi Leute!

Angenommen ich würde gern Support für den SHT40 hinzufügen wollen, weil ich da eventuell u.U. einen Sack voll hier hab, und keine neuen Sensoren kaufen will. Wie geh ich dann am besten vor?
Ich frag deshalb so blöd, weil mir eure Projektstruktur mit den Symlinks, Skripten etc. noch nicht geläufig ist. die OGM-SensorDevices hab ich gefunden und da eine SensorSHT4x.cpp und .h zu machen die den Sensor ausliest ist nicht das Problem, das krieg ich hin. Aber wie mache ich das mit meinem geforkten Repo am besten in der Projektstruktur?. Was muss ich an der ETS Seite ändern, damit ich nicht stolpere und mir dort was zerschieße?
Könntet ihr mich da evtl. ein wenig an der Hand nehmen?

LG
Wolfgang

[Ing-Dom]

das Sensormodul ist hier nicht unbedingt der beste Einstieg - du besteigst ja auch nicht zuerst die Eigner Nordwand

Aber wie mache ich das mit meinem geforkten Repo am besten in der Projektstruktur?

nachdem du das repo geclont und restored hast änderst du einfach das gitrepo auf deinen fork / branch (git clone)..

Was muss ich an der ETS Seite ändern, damit ich nicht stolpere und mir dort was zerschieße?

Wir haben dafür idr die Dev oder Beta Applikations-ID. Hier wird es immer schwierig wenn mehrere Leute an einem arbeiten. das geht nur im engen Austausch - oder du baust dir einfach eine neue Version und importierst diese aber nur in eine ETS in einer VM die du danach einfach verwirfst.

[MAKERWOLF]

das Sensormodul ist hier nicht unbedingt der beste Einstieg - du besteigst ja auch nicht zuerst die Eigner Nordwand

Naja, in der ETS kann man den SHT4x schon auswählen (wenn wohl auch nicht absichtlich), und da einfach einen Sensor dazugeben erscheint mir als Österreicher als keine allzugroße alpinistische Leistung 😅 Ist das so viel mehr als copy and paste, rename + funktion anpassen?

nachdem du das repo geclont und restored hast änderst du einfach das gitrepo auf deinen fork / branch (git clone)..

Ah ja, das macht wohl sinn.

Wir haben dafür idr die Dev oder Beta Applikations-ID.

Ja das hab ich schonmal wo gelesen, wo wird die festgelegt? Ich mach also quasi ein eigenes Device für die ETS oder? Praktisch ein "UP1 8x SHT-dev" ...

Hier wird es immer schwierig wenn mehrere Leute an einem arbeiten. das geht nur im engen Austausch - oder du baust dir einfach eine neue Version und importierst diese aber nur in eine ETS in einer VM die du danach einfach verwirfst.

[/QUOTE]

Das verstehe ich nicht. Ich dachte ich mach das bei mir lokal und wenn ich feststelle, dass das läuft, mach ich einen PR der nur die Teile des codes beinhaltet, die auch die Funktion verfolgen. Ich muss ja die Dev/Beta ApplikationsID nicht weitergeben, die hab ich ja nur lokal.
Hab ich da was nicht verstanden?

Ich weiß schon, dass es viele Stolpersteine gibt, aber irgendwo muss ich ja mal anfangen 🤗

[traxanos]

und da einfach einen Sensor dazugeben erscheint mir als Österreicher als keine allzugroße alpinistische Leistung

dann kennst du die ETS nicht. da fallen mir viel fallstricke ein. es könnte sein das dass dropdown keine neuen einträg zulässt weil der speicher nicht vorhanden ist über eine komplexe verschachtelung von vielen dropdowns.

du kannst auch nicht einfach in der ets was ändern! du musst für jede änderung eine eigene version machen, die niemals mit einer vorhanden kollidieren darf.

Ich muss ja die Dev/Beta ApplikationsID nicht weitergeben

du kannst im AFxx arbeiten. die nutzen wir alle nur für uns selber. und ja alles nur lokal nie öffentlich sonst kommt irgendwann das böse erwachen.

Ich weiß schon, dass es viele Stolpersteine gibt, aber irgendwo muss ich ja mal anfangen

dafür ist die ETS nicht das beste. vielleicht könntest du ja für die implementierung erstmal irgend einen vorhanden eintrag nutzen. so dass du nicht an die ets musst. und dann passt man das später final an.

[traxanos]

Wenn du wirklich hier mehr mitarbeiten willst, dann macht es ggf sinn, wenn man dir eine "Schulung" per Teams oder so gibt. Da kannst du dann mal ca 1-2 Stunden einplanen für die absoluten Basic.

[MAKERWOLF]

Nein, ich kenn die ETS bekannterweise überhaupt nicht, und ich hatte ehrlich gesagt auch nicht vor groß ETS-Seitig viel zu tüfteln. Wie gesagt, der SHT4 ist ja im dropdown schon drinnen, und den I2C code so anzupassen, dass er die richtigen Register liest läuft ja nur in C++, oder überseh ich sonst noch was?

Ich bin halt echt kein Fan von: mach das nicht, das ist zu schwer. Ich lauf lieber ins Feuer, zu sagen: nö, war zu hart, das kann ich dann immer noch, aber ich würds gern probieren und frag deshalb um Guidance 🤗

[traxanos]

aber wenn das SHT4 schon drinne ist musst du ja auch nix anpassen. aber ohne paar grundlagen wirds halt echt schwierig. da ist manchmal sich etwas zeigen lassen einfach. weil 1-2 stunden erspart dir hinterher viele stunden ausprobieren

[MAKERWOLF]

Ja genau deshalb schreib ich ja hier 🤷♂️
Der SHT4x ist nur in der ETS, in der Firmware nicht. Spuckt auch nur 0° aus. Verwendet auch andere Register als der SHT3x. Er wird auch nicht in der unterstützten Liste geführt.

[Ing-Dom]

wenn der SHT4x schon in der Liste drin ist, dann musst du mit der ETS GAR NICHTS machen.
Sondern einfach nur die FW erweitern / korrigieren.
OFM-THPSensorModule unterstützt den SHT4x, da sind schon ein paar Register / Commandos anders - da muss man aufpassen!
https://github.com/OpenKNX/OFM-THPSe...nnel_SHT4x.cpp

[MAKERWOLF]

wenn der SHT4x schon in der Liste drin ist, dann musst du mit der ETS GAR NICHTS machen.
Sondern einfach nur die FW erweitern / korrigieren.

Ja davon bin ich eben ausgegangen, du musst ja nicht gleich schreien 😅

OFM-THPSensorModule unterstützt den SHT4x, da sind schon ein paar Register / Commandos anders - da muss man aufpassen!
https://github.com/OpenKNX/OFM-THPSe...nnel_SHT4x.cpp

Ja deshalb dachte ich ja, wenn der SHT3 schon drin ist, dann ändere ich die Register und Kommandos entsprechend ab, und schon ist support da. Aber in dem Modul das im Auge hatte ist der Support eh drin, aber im anderen nicht. Ich bin gerade etwas verwirrt ...

[Ing-Dom]

ja hier gibts eine parallele Entwicklung für manche Sensoren. das "THP" Sensormodule ist nur in der "SEN-UP1-8xTH" FW für den SEN-UP1-8xTH drin.. nicht aber in der OAM-SensorModule..
Wesentlicher Unterschied, THP kann mehrere Sensoren gleichen Typs an mehreren Kanälen. Dafür viel weniger Sensoren und viel weniger Funktionen.

[mumpf]

Hi,

da es um mein Modul geht, sag ich jetzt auch mal was dazu .
Im Sensormodul ist der SHT40 nicht implementiert und nicht verfügbar. Es wird nur der SHT3x unterstützt.
Wenn du in OGM-SensorDevices den SHT40 implementieren magst, übernehme ich gerne den ETS-Teil. Die SensorDevices sind schon so aufgebaut, dass man zusätzliche Sensoren recht einfach integrieren kann.
Wenn Du willst, können wir den ETS-Teil dann auch in einer Telko gemeinsam machen und ich kann Dir so auch ein paar Infos zu unserer Arbeitsweise und der Projektstruktur geben.

Die Implementierung vom THPSensormodule und Sensormodule ist komplett unabhängig gelaufen, beides wurde begonnen, bevor es OpenKNX überhaupt gab. Somit haben die Implementierungen nicht wirklich was miteinander zu tun.

Gruß, Waldemar

[Ing-Dom]

Ja genau deshalb schreib ich ja hier 🤷♂️
Der SHT4x ist nur in der ETS, in der Firmware nicht. Spuckt auch nur 0° aus. Verwendet auch andere Register als der SHT3x. Er wird auch nicht in der unterstützten Liste geführt.

ich glaube du musst mal klartext sprechen von was du eigentlich sprichst. Präzision ist wichtig.
In welcher Applikation ist denn der SHT4x enthalten?

[MAKERWOLF]

Ahja, Danke für eure Antworten, jetzt wird das Bild schon viel klarer! 🤗

Hi,
Wenn Du willst, können wir den ETS-Teil dann auch in einer Telko gemeinsam machen und ich kann Dir so auch ein paar Infos zu unserer Arbeitsweise und der Projektstruktur geben.

Das wäre richtig super! Da komm ich gern drauf zurück! 🚀

Die Implementierung vom THPSensormodule und Sensormodule ist komplett unabhängig gelaufen, beides wurde begonnen, bevor es OpenKNX überhaupt gab. Somit haben die Implementierungen nicht wirklich was miteinander zu tun.

Das macht Sinn, der Code liest sich auch sehr unterschiedlich, hab da gestern Abend mal kurz drüber geblickt und sowas in der Art schon vermutet. Gibts da Ideen/Vorhaben/Visionen ob und wie man die Module zusammenführen könnte? Würde wahrscheinlich zwecks der Modularität sinnvoll sein sich auf ein einheitliches Komponentensystem zu einigen, ähnlich wie die Components in ESPhome.

ich glaube du musst mal klartext sprechen von was du eigentlich sprichst. Präzision ist wichtig.
In welcher Applikation ist denn der SHT4x enthalten?

Ja da hast du Recht, retrospektiv muss ich zugeben, dass ich zum Verfassungszeitpunkt die nötige Klarheit selbst noch nicht hatte 😅
Der SHT4x ist in der SEN-UP1-8xTH enthalten. Ich hab einen versuchsweise angehängt, und mein Temperatur KO spuckt nur 0° aus, hab aber auch noch nicht am I2C Bus geschaut, weil ich erst auf den falschen Code im anderen Modul gekommen bin, und gesehen hab, dass dort gar kein SHT4x ausgelesen wird und so zu falschen Schlüssen gekommen bin 😅

[traxanos]

Ich persönlich sehe ja immer noch einen Unterschied zwischen einem einfachen und generischen SensorModul der dann z.B. in einem Taster oder PM integriert ist um dann die paar unterschiedlichen Sensoren anzubinden und einem richtigen Sensordevice das mit viele Sensoren daher kommt und umgehen gehen muss. Das die komplette UI würde ich unterschiedlich gestalten.

Das Problem ist halt einfach das die ETS für solche flexiblen Produkte nie ausgelegt wurde. Aber ob und wie das geplant ist muss der Owner mumpf sagen.