HB-UNI-Sensor1 - Neuauflage

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

turrican944
Beiträge: 287
Registriert: 29.05.2019, 22:19
Wohnort: Bargfeld
Hat sich bedankt: 3 Mal
Danksagung erhalten: 22 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von turrican944 » 09.09.2020, 13:35

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

turrican944
Beiträge: 287
Registriert: 29.05.2019, 22:19
Wohnort: Bargfeld
Hat sich bedankt: 3 Mal
Danksagung erhalten: 22 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von turrican944 » 09.09.2020, 20:04

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.
Gruß Florian

ivo-int
Beiträge: 136
Registriert: 13.04.2020, 08:55
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 13 Mal
Danksagung erhalten: 5 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von ivo-int » 30.11.2020, 08:48

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
_______________________________________________________________________________________________________
Raspberrymatic auf einem Raspi 4 4GB (HB-RF-USB-2) mit 2 LAN Gateways,
42 RF Geräte, 5 IP Geräte und 21 Cuxd Geräte, 22 RF Eigenbau Geräte
hm_pdetect, E-Mail, XML-API, JB HB Devices, HB-TM-Devices-AddOn, CUx-Daemon, CCU-Historian auf einem separaten Raspi

TomMajor
Beiträge: 1343
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 104 Mal
Danksagung erhalten: 260 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von TomMajor » 30.11.2020, 19:23

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,
Viele Grüße,
Tom

jp112sdl
Beiträge: 8057
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 436 Mal
Danksagung erhalten: 983 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von jp112sdl » 30.11.2020, 20:01

TomMajor hat geschrieben:
30.11.2020, 19:23
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

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

TomMajor
Beiträge: 1343
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 104 Mal
Danksagung erhalten: 260 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von TomMajor » 01.12.2020, 01:08

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?
Viele Grüße,
Tom

jp112sdl
Beiträge: 8057
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 436 Mal
Danksagung erhalten: 983 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von jp112sdl » 01.12.2020, 07:22

TomMajor hat geschrieben:
01.12.2020, 01:08
Ist nur das Patchen betroffen?
Jap
TomMajor hat geschrieben:
01.12.2020, 01:08
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.
TomMajor hat geschrieben:
01.12.2020, 01:08
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 :evil:
Ist auch toll, wenn man sich ein Diff im Github anschauen will... da ist dann mal die ganze Datei geändert :evil:

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.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

PN sind deaktiviert!

ivo-int
Beiträge: 136
Registriert: 13.04.2020, 08:55
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 13 Mal
Danksagung erhalten: 5 Mal

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von ivo-int » 01.12.2020, 12:29

Hallo zusammen
TomMajor hat geschrieben:
01.12.2020, 01:08
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.
jp112sdl hat geschrieben:
01.12.2020, 07:22
TomMajor hat geschrieben:
01.12.2020, 01:08
Ist nur das Patchen betroffen?
Jap
TomMajor hat geschrieben:
01.12.2020, 01:08
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.
TomMajor hat geschrieben:
01.12.2020, 01:08
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 :evil:
Ist auch toll, wenn man sich ein Diff im Github anschauen will... da ist dann mal die ganze Datei geändert :evil:

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
_______________________________________________________________________________________________________
Raspberrymatic auf einem Raspi 4 4GB (HB-RF-USB-2) mit 2 LAN Gateways,
42 RF Geräte, 5 IP Geräte und 21 Cuxd Geräte, 22 RF Eigenbau Geräte
hm_pdetect, E-Mail, XML-API, JB HB Devices, HB-TM-Devices-AddOn, CUx-Daemon, CCU-Historian auf einem separaten Raspi

TomMajor
Beiträge: 1343
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 104 Mal
Danksagung erhalten: 260 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von TomMajor » 01.12.2020, 12:59

jp112sdl hat geschrieben:
01.12.2020, 07:22
TomMajor hat geschrieben:
01.12.2020, 01:08
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 :evil:
Ist auch toll, wenn man sich ein Diff im Github anschauen will... da ist dann mal die ganze Datei geändert :evil:

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. :wink:
Viele Grüße,
Tom

TomMajor
Beiträge: 1343
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 104 Mal
Danksagung erhalten: 260 Mal
Kontaktdaten:

Re: HB-UNI-Sensor1 - Neuauflage

Beitrag von TomMajor » 06.12.2020, 18:20

turrican944 hat geschrieben:
04.09.2020, 06:39
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.
Viele Grüße,
Tom

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“