HB-UNI-Sensor1 - Neuauflage

[turrican944]

Moin
Ja ESP wäre kein Problem aber ich will eigentlich so weit wie möglich auf die ESP mit WLAN verzichten.

[turrican944]

Moin
Ich habe mir noch einen Sensor gebaut der im Badezimmer hängt und nur Luftfeuchtigkeit und Temperatur misst und zusätzlich hängt ein Taster dran mit dem ich meine Lüfter im Badezimmer triggern kann. Nun muss natürlich nicht unbedingt Lux usw angezeigt werden, reicht es die aus der XML Datei raus zu nehmen oder besser auch gleich im payload raus , spart dann ja wohl auch etwas Daten bei der Übertragung.

[ivo-int]

Hallo Tom

Jerome hat über ein Problem mit seiner Addon viewtopic.php?f=65&t=63030&p=622898#p622571 informiert. Betrifft das dein Addon HB-TM-Devices-AddOn ebenfalls

Gruss Ivo

[TomMajor]

Was genau ist das Problem?
Ich lese in deinem link was von Zeilenumbruch unix/dos (und das die 3.55 laut jmaus in 4 Wochen kommt).
Kann jemand erklären was das Problem ist, welche Dateien betroffen sind und warum das bei 3.55 anders ist als bisher?
Danke,

[jp112sdl]

Was genau ist das Problem?
Ich lese in deinem link was von Zeilenumbruch unix/dos (und das die 3.55 laut jmaus in 4 Wochen kommt).
Kann jemand erklären was das Problem ist, welche Dateien betroffen sind und warum das bei 3.55 anders ist als bisher?
Danke,

Den Bruch mit den Linefeeds gab es schon von der 3.51 zur 3.53.
schau mal in meine Commits.

Bei der 3.55 hat sich zudem noch die Patchsektion in der datapointconfigurator.fn geändert.
Das hab ich noch nicht im GitHub committed

[TomMajor]

Hallo Jerome und Ivo,

ich muss gestehen mir fehlt momentan die Zeit mir das im Detail anzuschauen, aber wenn es eine Lösung gibt kann ich die sicher nachziehen, aber wohl frühestens in 2-3 Wochen.

Ist nur das Patchen betroffen? Im HB-TM-Devices-AddOn patche ich nichts, sondern führe nur die install Skripts aus, kopiere die Dateien, Symlinks usw.

Nur im HB-TM-JP-AddOn-Reduced patche ich diese Dateien

Code: Alles auswählen

PATCHFILE1=/www/rega/esp/functions.fn
PATCHFILE2=/www/config/ic_common.tcl
PATCHFILE3=/www/webui/webui.js
PATCHFILE4=/www/rega/pages/tabs/admin/views/programs.htm
PATCHFILE5=/www/rega/esp/side.inc

Also ist eventuell HB-TM-Devices-AddOn nicht betroffen (UniSensor usw.), nur HB-TM-JP-AddOn-Reduced?

Und was ist allgemein gesprochen der Grund für die Probleme, hat sich der EOL Type von zu patchenden Dateien einfach mal so von einer RM Version auf die andere geändert und das patchtool kommt damit nicht mehr zurecht?

[jp112sdl]

Ist nur das Patchen betroffen?

Jap

Also ist eventuell HB-TM-Devices-AddOn nicht betroffen (UniSensor usw.)

Davon gehe ich aus. Wenn da nur XML Files kopiert und ein bisschen Sprache übersetzt wird, sollte es weiterhin passen.

Und was ist allgemein gesprochen der Grund für die Probleme, hat sich der EOL Type von zu patchenden Dateien einfach mal so von einer RM Version auf die andere geändert und das patchtool kommt damit nicht mehr zurecht?

Genau.
Da hat bei eQ-3 jemand den Editor gewechselt
Ist auch toll, wenn man sich ein Diff im Github anschauen will... da ist dann mal die ganze Datei geändert

Und für [das BusyBox-]patch ist eine Zeile, die sich zwar inhaltlich gleicht, am Ende jedoch im (CR)LF unterscheidet, nicht die selbe.
Also prüfe ich erstmal, ob "Patchfile" und "zu patchendes" File den selben Linefeed nutzen und konvertiere ggf. das Patchfile.

[ivo-int]

Hallo zusammen

ich muss gestehen mir fehlt momentan die Zeit mir das im Detail anzuschauen, aber wenn es eine Lösung gibt kann ich die sicher nachziehen, aber wohl frühestens in 2-3 Wochen.

Tom bitte mach dir keinen Stress. Mein Ziel war lediglich dich zu informieren was ich in einem Tread von Jerome gelesen habe.

Ich wollte nur verhindern dass beim Release dann unerwartete Überraschungen auftauchen. Denn auch ich kann nicht alle Beiträge lesen. So entgeht mir auch das eine oder andere.

Ist nur das Patchen betroffen?

Jap

Also ist eventuell HB-TM-Devices-AddOn nicht betroffen (UniSensor usw.)

Davon gehe ich aus. Wenn da nur XML Files kopiert und ein bisschen Sprache übersetzt wird, sollte es weiterhin passen.

Und was ist allgemein gesprochen der Grund für die Probleme, hat sich der EOL Type von zu patchenden Dateien einfach mal so von einer RM Version auf die andere geändert und das patchtool kommt damit nicht mehr zurecht?

Genau.
Da hat bei eQ-3 jemand den Editor gewechselt
Ist auch toll, wenn man sich ein Diff im Github anschauen will... da ist dann mal die ganze Datei geändert

Und für [das BusyBox-]patch ist eine Zeile, die sich zwar inhaltlich gleicht, am Ende jedoch im (CR)LF unterscheidet, nicht die selbe.
Also prüfe ich erstmal, ob "Patchfile" und "zu patchendes" File den selben Linefeed nutzen und konvertiere ggf. das Patchfile.

Jerome Danke für die Klärung.

Gruss Ivo

[TomMajor]

Und was ist allgemein gesprochen der Grund für die Probleme, hat sich der EOL Type von zu patchenden Dateien einfach mal so von einer RM Version auf die andere geändert und das patchtool kommt damit nicht mehr zurecht?

Genau.
Da hat bei eQ-3 jemand den Editor gewechselt
Ist auch toll, wenn man sich ein Diff im Github anschauen will... da ist dann mal die ganze Datei geändert

Und für [das BusyBox-]patch ist eine Zeile, die sich zwar inhaltlich gleicht, am Ende jedoch im (CR)LF unterscheidet, nicht die selbe.
Also prüfe ich erstmal, ob "Patchfile" und "zu patchendes" File den selben Linefeed nutzen und konvertiere ggf. das Patchfile.

Danke für die Erläuterung, Jerome.

Git kann man ja konfigurieren das es line ending / OS neutral ein- bzw. auscheckt.
https://docs.github.com/en/free-pro-tea ... ne-endings

Every time you press return on your keyboard you insert an invisible character called a line ending. Different operating systems handle line endings differently.
When you're collaborating on projects with Git and GitHub, Git might produce unexpected results if, for example, you're working on a Windows machine, and your collaborator has made a change in OS X.
You can configure Git to handle line endings automatically so you can collaborate effectively with people who use different operating systems.

Vielleicht reicht es, das jemand mit gutem Draht zu eQ-3 das dort einsteuert?

@Ivo passt schon, auch wenn man es vlt. aus Zeitgründen nicht sofort ändern kann, eine frühe Warnung ist immer gut.

[TomMajor]

Moin
Ja denn von Jerome habe ich auch schon gesehen, ich hatte mir den Uni Sensor 1 ausgesucht weil der den digitalen Eingang mit überträgt. Momentan habe ich auch wenig Zeit und wenig Ahnung von c++. Aber man ist ja lernfähig muss ich mich mit beschäftigen wie man die Klasse aufbohrt das sie mehr Sensoren kann oder einen digitalen Eingang von Jerome s Sensor einbauen.

Es hat zwar wegen Zeitmangel etwas länger gedauert als ursprünglich angenommen, aber jetzt unterstützt der HB-UNI-Sensor1 auch mehrere DS18B20 Temperatursensoren.
Die Temperaturen stehen an dieser Stelle im Code zur Verfügung und können bei Bedarf aktiviert werden:

Code: Alles auswählen

// Beispiel: Hier sind alle DS18B20 Temperaturen im Array falls mehrere DS18B20 an einem Pin/Bus verwendet werden
// Dafür muss DS18X20_COUNT in der Konfigurationsdatei angepasst werden!
// for (uint8_t i = 0; i < DS18X20_COUNT; i++) {
//    temp10Array18x20[i] = ds18x20[i].temperature();
//}

Über den Mechanismus Benutzerspezifische Sensordaten können dann die Temperaturen in Payload und WebUI verfügbar gemacht werden.