Beiträge von uzlopak

Ich hab jetzt auch mal das tsc angeschrieben und nach den geplanten backports gefragt.

Ich weiß aber keinen guten Grund auf node20 und 22 zu bleiben.

Es ist wirklich geil. Wir haben ja in node 18 zu openssl 3.0 migriert, weil openssl 1.1 komplett deprecated wurde. Openssl 3.0 hatte zwar ne bessere Architektur aber hatte performance bottlenecks ohne Ende. Alles rund um crypto war langsamer.

Mit openssl 3.5.1 kommt wieder richtig Dampf in den Kessel!

Das bedeutet auch, dass Video- und Audiostreams von eufy Geräten auf node 24.5 im Vergleich zu node 20.11.1 noch flüssiger laufen sollten.

Node 24.5.0 wurde am Mittwoch veröffentlicht: Und das hat das Upgrade auf openSSL 3.5.1

Ich hab jetzt auch einen der tests von nodejs genutzt - test/parallel/test-crypto-rsa-dsa.js - um es zu testen.

Lange Rede, kurzer Sinn: PKCS1 mit Padding funktioniert auf Node 24.5.0 wieder.

Viel Spaß.

Nachtrag:
https://github.com/homebridge-…ecurity/plugin/issues/708

sschuste

Wenn wir schon so sind, dann muss man auch sagen, dass 0 nicht genutzt werden kann. Ich hab schon lange kein Windows Rechner mehr gehabt, aber früher konnte man auch ohne Probleme privileged ports nutzen ohne dass von Windows gemeckert wurde.
Aber hier geht es um einen Linux-Rechner. Und darum sind die privileged ports relevant. Also kann man jeden freien Port >= 1024 nutzen.

Portrange von 0 bis 1024 sind in linux privileged. Darum auch die hohen Portnummern wie 8080.

Laut ner Internetrecherche versuchst du auf die HAP zuzugreifen und nicht auf die UI.

Achja, sschuste, du fragtest nach den smart displays. Ich meine damit Lenovo ThinkSmart View. Der hat 8 GB Speicher. Wenn ich den entsprechend flashe und termux draufpacke und es als Server nutzen will, dann hab ich vielleicht 1 GB für homebridge plugins. Wenn dann also die plugins 150 MB groß sind, dann ist nach 7-8 Plugins Schluss, obwohl bei robuster Programmierung vielleicht hunderte Plugins möglich wären.

sschuste

Jo, schau mal bspw.:

137M homebridge-hue

165M homebridge-weather-plus

Für homebridge-hue habe ich vorhins einen PR erstellt.

chore: remove transient depenedency googleapis by Uzlopak · Pull Request #1216 · ebaauw/homebridge-hue

hi @ebaauw , fakegato-history is supporting the ability to configure google drive to store logging data when the connection is not working. I dont think that…

github.com

Dann wird die auf deiner Platte nur noch quasi 7mb belegen. Man kann ja mit homebridge-hue nicht den fakegato history für google drive konfigurieren. Aber den homebridge-weather-plus schon.

Oder dein homebridge-zp plugin. Das ist 11 MB groß. u.a. nutzt es den bonjour-hap. Hab dafür auch nen PR erstellt damit deep-equal durch fast-deep-equal ausgetauscht wird. Dadurch wird nicht nur die performance besser sondern man lädt auch 2 mb weniger daten. Und es ist ja nicht so, dass es eine 2 mb große datei wäre. SOndern viele viele kleine. Viele viele Dateien zu lesen dauert länger als eine Datei zu lesen. Wenn man also das konzentriert angeht, dann kann man erheblich die startup zeit verbessern.

Das homebridge-people ist ja richtig veraltet. Wenn man es refaktoriert, dann wäre es bestimmt insgesamt ca. 50 kb groß und nicht 12 Mb. Wenn man es modernisiert und für neueste homebridge anpasst wäre es bestimmt größer, aber würde wahrscheinlich nicht die 1Mb Grenze brechen.

Aber ich finds definitiv nicht schlimm. Ich finde es eigentlich richtig geil, dass es soviele bestehende lösungen gibt für soviele interessante Ideen. Das homebridge-people ist ja auch ne interessante Idee, auf die wäre ich nicht gekommen ;).

HolgerKR

Ich wollte dich nicht vergraulen ;). Steht das KR für Krefeld?

Ich hab gerade nochmal explizit nachgeschaut, da ich ja auch persönlich hoffe, dass wir bald in nodejs OpenSSL upgraden können. Das Problem ist nämlich, dass OpenSSL 3.0 sacklahm ist. Wir hatten das ja vor fast 2 Jahren im performance team von nodejs besprochen.

Perf regression on crypto.verify · Issue #72 · nodejs/performance

On NodeJS 16.x, crypto.verify made 30k op/s (ref) But on NodeJS 18.x, crypto.verify downgrade to 6~7k op/s (ref). I initially discover this on this pr:…

github.com

Zumal afaik OpenSSL ja erklärt hat, dass die ABI von OpenSSL gleichbleiben sollte, sollte es eigentlich kein Problem sein. Problem war immer der QUIC und http3 support für nodejs. Und OpenSSL hat echt nen langen Entwicklungszyklus.

Jedenfalls: NodeJS wird wohl bald ein Update von OpenSSL auf Version 3.5 erhalten.

Update on QUIC · Issue #57281 · nodejs/node

Just wanted to give an update on the situation with the QUIC implementation. At this point I'm quite glad that I didn't move forward on the implementation that…

github.com

OpenSSL 3.2 und neuer haben den notwendendigen Flag um PKCS1 mit Padding in nodejs zum decrypten zu nutzen.

Dann wirst du auch dein eufy plugin mit neuestem Node nutzen können ;).

HolgerKR. Den Spruch fand ich schon sehr lahm.

Ich meinte nicht den RAM sondern den Festspeicher. Ich überlege mir derzeit was ich für ne Hardware nehme um die Homebridge zu installieren und wenn ich sehe, dass dann manche plugins laut npmgraph 250 mb und mehr belegen, dann frag ich mich ob da kein Problembewusstsein gibt.

Es macht ja auf diesen Smart Displays ja nen Unterschied, wenn ich nur 2 GB habe um alles drauf zu installieren. Sind die Plugins 250mb statt vielleicht 5 MB groß, dann belege ich unnötig raren Festspeicher.

Ich hab bspw. heute ne Menge PRs für werift-webrtc, eine dependency vom ring Plugin, erstellt.

Pull requests · shinyoshiaki/werift-webrtc

WebRTC Implementation for TypeScript (Node.js), includes ICE/DTLS/SCTP/RTP/SRTP/WEBM/MP4 - Pull requests · shinyoshiaki/werift-webrtc

github.com

Muss noch eine Alternativ Lösung für eine Lodash Funktion finden, dann kann man lodash mit 1,4 mb entfernen.

Was für Plugins nutzt du in deiner homebridge?

Habt ihr auch das Gefühl, dass die Plugins zuviel Speicher belegen? Ist das überhaupt ein Problem, dass auf dem Bildschirm ist?

Man kann wohl enableEmbeddedPKCS1Suppor auf true setzen und dann funktioniert es wohl auch auf neueren node versionen.

Kannst du mir mal bitte das plugin benennen? Warum sollte es relevant für die doorbell sein, welches node auf deinem proxmox läuft

Meiner Meinung nach gibt es seit node 18 keine großartigen Änderungen, die Besorgnis bei einem Upgrade auslösen sollten.

Bei einem Major Release wird idR die V8 Engine upgegraded und paar neue features freigeschalten.

Ich bin bis Mittwoch in Portugal. Danach kann ich mir das weiter zu Gemüte führen. Ich werde schon versuchen, dass es keine breaking changes hat.

Ich wollte eigentlich schauen, dass ich ggf. das einfach gebundled anbiete, damit man nicht großartig viel machen muss, damit man es testen kann.

Aber hier kommt mal wieder dieses meme zu tragen, wonach der node_modules Verzeichnis zu den schwersten Objekten im Universum sind.

npmgraph - NPM Dependency Diagrams

npmgraph.js.org

Wenn ich das bundlen will, dann sind das 232 MB die ich da bundlen müsste. Und das nur weil fakegato-history unbedingt das feature haben will, dass man auf google drive sichern kann.

Hab da jetzt nen PR rausgehauen, werde aber ggf. dafür nur ein override in die package.json in mein plugin reinpacken, oder in esbuild googleapis als external markieren. Dann sollten das die Installationsgröße um 198 Mb senken ;).

Wenn SeydX dazu bereit wäre...

Was mir persönlich bissl aufn Keks geht sind so willkürliche Verzögerungen. So nach dem Motto: Warte ne 250ms damit (hoffentlich) der HistoryService startet..

Hättet ihr den Lust das zu testen, wenn ich den code refaktoriert habe?

Ich überarbeite aus Spaß derzeit das fritzbox plugin. Es ist in Javascript geschrieben, sodass static code analysis im Vergleich zu Typescript nicht von Haus aus gibt.

Derzeit schreibe ich im Grunde ganz viel jsdoc kommentare um den Code halbwegs modern zu machen.

Ohne das Changelog im letzten Post zu gelesen zu haben, habe ich schon vieles modernisiert.

Ich vermute aber auch, das die Originalimplementierung paar Konventionen bricht weil es direkt Characteristics und Services direct zum HAP Objekt hinzufügt. Das funktioniert aber nur bedingt. Es gibt jetzt aber die Characteristic Ping und den Service Switch in homebridge, die es wohl früher nicht gab. Das bedeutet, dass die Fritzbox Plugin Implementierung diese Standard-Implementierungen überschreibt, und praktisch das ganze System stört. Ich vermute dass andere Plugins entweder ihre Characteristics und Services entweder Separat halten oder zumindest eindeutig prefixen.

Außerdem hab ich schon mehrere Bugs gefunden. Schreibfehler im Code. Copy Paste Fehler. Und es gibt keinerlei Tests für den code.

Nervig.