Wobei man bei Wikipedia schon noch höhere Raten in der Spezifikation findet: Ultra HD Blu-ray – Wikipedia
50 GB (dual-layer,[1] 82 Mbit/s)
66 GB (dual-layer,[1] 108 Mbit/s)
100 GB (triple-layer,[1] 128 Mbit/s; BDXL[1])
128 GB (quad-layer; BDXL)[1]
Gab hier auch schon Diskussionen zu FireTV 100 Mbit/s LAN-Adapter, wo manche UHD Medien dann Probleme machten, und mit WLAN ging es dann ...
Ich habe mir die Fehlermeldung aus dem tvh-Fenster noch mal angesehen:
spawn: error: No plugin can handle URL: pipe:1
Wenn ich eine URL aufrufe, mit der streamlink nicht zurechtkommt steht da allerdings
error: No plugin can handle URL: wetter.com
Hmm, bin ich jetzt verwirrt? Wieso steht da nicht die URL in deiner Fehlermeldung. Streamlink hat mit der Zeit auch paar Optionen geändert. Vielleicht Mal probieren wie in meinem ersten Beispiel pipe:///pathto/streamlink URL best -o -. Das ist nach meinem Gedächtnis die Art Kommandozeile, die schon immer funktioniert hat mit streamlink.
Nach dem was du geschrieben hast, hast du sicherlich exakt die Kommandozeile aus #1 aufgerufen und nur --stdout durch -o file ersetzt, Rest gelassen. Würde das noch bisschen anders testen, --stdout lassen und dann halt > filename am Ende. Dann auch noch prüfen, ob das File abgespielt werden kann, und ob das wirklich pures mpegts ist (z.B. mit mediainfo/vlc auf anderem Rechner). Für mich steht auf der Streamlinkseite ein Mal verwirrend was von Default matroska. Bei mir kommt aber schon mpegts raus.
Vielleicht habe ich auch sonst noch was missverstanden. Du hast das nicht als m3u-IPTV-Playlist implementiert, sondern die Kommandozeile direkt irgendwo in tvh eingetragen? War irgendwie davon ausgegangen, das sei halt die "URL-Zeile" einer m3u, und #EXTM3U und #EXTINF hattest du einfach nicht gezeigt. Ich würde es auf jeden Fall noch mal mit der Playlist probieren. Und ggf. auch noch --loglevel debug mitgeben (und evt. auch --logfile.)
Als Workaround könnte liveproxy dienen (nachzulesen auf dem streamlink github). Früher gab es auch noch streamlinksrv auf github (und in e2-Images gibt es den oft noch).
Die Fehlermeldung kommt von streamlink, nicht tvh. (Nach meinem Verständnis und meinem Gedächtnis). tvh zeigt hier halt stderr von dem gespawnten streamlink-Prozess an. Ist zwar bisschen anderes die Fehlermeldung als bei mir - hängt aber sicherlich auch von der genauen streamlink version (und einkompilierten plugins) ab.
Deine Kommandozeile sieht meines Erachtens ok aus - kann das aber leider im Moment selbst nicht unter tvh testen.
Mir scheint streamlink kommt grundsätzlich nicht mit der URL zurecht (und ich meine mich auch zu erinnern, dass das ein typisches youtube/streamlink Prob ist, wo man nix machen kann ...) ich erhalte auf der Kommandozeile
streamlink https://www.youtube.com/watch?v=JhajwzEv1Fo best
[cli][info] Found matching plugin youtube for URL https://www.youtube.com/watch?v=JhajwzEv1Fo
error: Unable to open URL: https://youtube.com/get_video_info (410 Client Error: Gone for url: https://www.youtube.com/get_video_info?video_id=JhajwzEv1Fo&html5=1&el=detailpage)
Probier doch mal mit einer anderen URL, wie ein Standard Live-TV HLS Stream. Dafür braucht man zwar nicht streamlink und da ginge auch die ffmpeg-Pipe. Wird dir aber die grundsätzlich Funktionalität streamlin in tvh in deinem Setup verifizieren. Z.B. streamlink --default-stream best --url https://stv-live.akamaized.net/hls/live/2031020/lingeoSTVDEwebBU/master.m3u8 geht hier.
Und in TVH -> Konfiguration -> Kanal / EPG -> Kanäle -> Spalte Limit EPG (evt. musst du die Spalte erst aktivieren): Steht da überall ne 0 oder ein anderes vernünftiges Limit?
Hast du schon Kodi -> Einstellungen -> PVR und TV -> Programmübersicht -> anzuzeigende zukünftige Tage geprüft?
Das ging leider noch nie (oder zumindest schon Jahre lang nicht) Kodi auf Fire TV Geräten aus dem Store zu installieren. Möglichkeiten gibt es zu Hauf: HOW-TO:Install Kodi on Fire TV - Official Kodi Wiki Selbst habe ich - wie von @Bobbi2021 auch empfohlen - adblink genutzt auf Windows PC.
Solche Antworten habe ich bisschen erwartet. Ich bin ja auch nicht erst seit gestern dabei und komme aus einer Zeit, wo es nicht ohne statische IPs ging. Bin verantwortlich für das Design sehr großer RZ-Umgebungen (mit > 1000 Servern pro Kunde und hohen Anforderungen an Verfügbarkeit). Dort selbstverständlich mit redundanter hochverfügbarer DHCP-Infrastruktur.
Das erspart mir beim Routerwechsel ne Menge Stress.
Ich hatte vor einem Jahr einen Routerwechsel - vollkommen problemlos. Mit > 50 Geräten im LAN (davon ca. 30 IoT Geräte). Hat alles auf Anhieb weiter funktioniert.
Es ist ein weiterer Punkt, der dafür sorgt, dass mein Gerät IMMER mit der gleichen Adresse erreichbar ist.
Klar. Ich frage mich: wofür brauch ich das? Samba meines Servers (ein HP Microserver, da vergesse ich dann den Namen hpms auch nicht) erreiche ich immer unter demselben Namen \\hpms, Webif meiner E2 Box unter http://vusolose, Webif von Kodi, von IoT Geräten, Telefon, AVR, Drucker, ...
Meine Beobachtung hier: typische Netzwerkthemen kommen oft und gerade im Zusammenhang mit statischen IPs vor. Kritische Technikermeetings (wenn was schief gegangen ist, im RZ) sind mir ein Gräuel, wenn die Admins von "dem 185er Server" reden (und damit halt die IP 10.x.y.185 meinen) statt von sagen wir oraclebe03 oder Storefront02. Klar, "alte Schule".
Ist meines Erachtens auch ein wichtiger Hinderungsgrund für erfolgreiche IPv6 Umstellung (weil halt allenthalben IP-Adressen, statt Namen konfiguriert sind - das umzukonfigurieren ist mühsam und Fehler-anfällig).
Ich weiß, dass es kein gutes Argument ist, dass das bei mir gut klappt ohne fixen IP-Adressen. Was ich selbst an Netzwerk programmiere nutzt selbstverständlich Namensauflösung (wo nötig) und ist IPv4 und IPv6 kompatibel.
Und nein, ich behaupte nicht, dass es keine Situationen gibt, wo man statische IP braucht, dass man einem DNS keine geben soll, dass eine fixe IP an der Außenkante oft schön wäre ... Im RZ wird oft auch "statisches DHCP" mit fixen Reservierungen angewendet (und auch im Heimnetz, viele Router können das und erspart die Konfig auf der Client-Seite. Mein Argument - bei normalem Home Use inkl. viel Nerds-Zeugs kann man sich das aber sparen).
Aber jetzt bin ich ruhig zu diesem Thema - wird eh nix bringen.
Die Prozessorauslastung ist bei beiden Systemen (LibreElec, J5005; unRaid, J3455) im unkritischen Bereich von 20%-30%.
Da könnten 20% - 30% schon kritisch sein (wenn sie sie sich auf die CPU und nicht auf einen Core beziehen). J5005 hat 4 Kerne, bei einer Aufgabe, die sich nicht auf mehrere Threads verteilt (und das kann bei VPN gut der Fall sein) ist bei 25% Schluss. Kann natürlich gut sein, dass du dir das schon angesehen hast ... Wenn da kein Prozess mit sagen wir 15% oder mehr Last ist, wird es nicht an der CPU-Auslastung liegen.
Ich frage mich, wieso man scheinbar immer (in typischen Kodinerds-Server/Service-Diskussionen) statische IPs benötigt. Bei mir funktionieren im Heimnetz Computernamen/Hostnamen vollkommen zuverlässig. Außer in einer Nerds-Community käme doch niemand mehr auf die Idee, statische IP-Adressen zu verwenden.
Mag aber sein, dass die Namen nur auf Fileserver funktionieren, wo Samba/Cifs läuft, und wenn das nicht installiert ist und nur NFS genutzt wird, fehlen die.
Ich weiß, dass hier viele Puristen auf NFS schwören. Meines Erachtens läuft sehr oft SMB vollkommen problemlos und performant. (Selbst war ich NFS-Nutzer seit ca. 1990, auch auf dem PC - heute brauche ich es kaum noch zu Hause mit Linux, Windows, MacOS, Android, IOS ...).
Schau dir im Kodi Wiki Mal den [definition='2','1']advancedsettings[/definition] Artikel an, dort den Bereich zur Slideshow - [definition='2','1']advancedsettings[/definition].xml - Official Kodi Wiki
Der Paramenter blackbarcompensation sollte es richten. (Wobei es meines Erachtens nicht perfekt erklärt ist - muss man vielleicht mal testen mit 0)
Dass man dafür [definition='2','1']advancedsettings[/definition] braucht und das nicht in der GUI machen kann, finde ich eigenartig. Vielleicht mal ein Feature-Request im Original-Kodi-Forum. Auch scheint mir die Default-Einstellung fragwürdig. Ich denke die meisten Leute wollen ihre Fotos sehen, wie sie sind. (Genauso wie wir typischerweise bei Filmen lieber schwarze Ränder haben, als Teil des Bildmaterials abgeschnitten).
Das mag schon sein. Aber in so einem Fall: wieso das Protokoll verantwortlich machen, und nicht die Hardware und SW? Ich habe da auch professionell viel getestet. Natürlich funktioniert unter optimalen Bedingungen immer alles. Und (gerade in Firmen-Umgebungen) ist auch die Durchlässigkeit von UDP ein Problem, auch (und wegen) Sicherheit (weil es grundsätzlich andere Angriffsmechanismen gibt - aber bei Streamen im Heimnetz und auch bei LiveTV aus dem Internet??).
Mein Argument: TCP hört sich grundsätzlich besser an. Wenn die Bedingungen schlechter werden, Anforderungen höher (an Bandbreite und Latenz) hat UDP grundsätzliche Vorteile. Das wollte ich ins Bewusstsein rufen.
Ich versuche nun aufzuhören, das Thema zu hijacken ...
TVHeadend (und wohl auch der Digibit?) benutzen zum Transport der Streams UDP. Das kann in Zusammenhang mit Switchen, ungünstiger Netztopologie, schlechtem Hardwaredesign (RPi) und hohem Transportaufkommen gerne mal zu Bildaussetzern führen.
Das will ich nicht grundsätzlich bestreiten (auf deine Korrektur komme ich zurück ...) In der Tat gilt selbstverständlich UDP als unzuverlässiger ("kann Pakete verlieren, ungeordnet übertragen, gibt keine Rückmeldung) als TCP. Und ist es für viele Situationen auch.
Allerdings, wenn man geringe Latenz will, hohe Bandbreite benötigt, das Netzwerk eh schon mit vielerlei Dingen ausgelastet ist (und QOS lasse ich jetzt man außen vor) hat sowohl theoretisch als auch praktisch UDP sehr große Vorteile. Die "Belastung" (ohne das jetzt genau zu definieren) des Netzes ist niedriger. Läuft (gerade bei Streams) noch gut, wenn TCP zu Abbrüchen neigt (und zu Diskussionen hier, man solle sich zuverlässigeres Netzwerk besorgen, höhere Bandbreite, Kabel ziehen, ...).
Ein Beispiel, bewusst mit WLAN. Magenta TV Live TV. Die nutzen UDP (mit rtp-Protokoll), 7 Mbit/s bei mir auch im WLAN absolut verlässlich. Mein Testprogramm hat in 24 h nicht ein verlorenes Paket gefunden, und auch nicht eines in falscher Reihenfolge (was erlaubt wäre - durch Auswertung der rtp-Header kann man das rausfinden). Gleiche Bedingungen mit WLAN, Stream von meinem Enigma2 Receiver, ähnliche Bandbreite. Der Stream (genau wie tvh) pure Transport-Streams (ts) mit TCP. Fängt leicht zu stottern an um später abzubrechen / sich total aufzuhängen (natürlich nur unter nicht zuu tollen Bedingungen).
Ich denke neben den reinen Transport-Eigenschaften sind da auch die Robustheit/Qualität der Programmierung mit maßgebend. Wer sich auf UDP verlässt rechnet automatisch mit Unzulänglichkeiten. Bei TCP kommt der Client (und der Server) ist das oft weniger robust programmiert (da man sich eh auf TCP verlassen kann) und jede Kleinigkeit führt zu nicht korrigierten Problemen bis zur Nichtfunktionalität.
Nicht ohne Grund nutzen auch oft Video-/Audio-Konferenz Lösungen oder auch Protokolle um im Rechenzentrum gerenderte Grafik auf einem Endgerät in Echtzeit darzustellen (z.B. Citrix ICA) UDP.
EDIT: Kleiner Zusatz. Was neben UDP vs. TCP da auch noch ne Rolle spielt. Tvheadend, genau wie Enigma2, streamen reinen Transport-Stream, ohne ein Protokoll oder ein Framework außen rum. HLS streamt auch über TCP, hat aber Aufsetzpunkte (TS wird fragmentiert in typischerweise wenige Sekunden lange Chunks). Diese puren TS-Streams sind zweifellos für Broadcast über den Ether (wo sie her kommen, aber auch nicht ohne zusätzliche Checks) bestens geeignet. Fürs Streaming (selbst im Heimnetz) aber halt bei der kleinsten Störung schmiert das leicht ab.
Hab' noch mal nachgeschaut, TVH macht TCP.
Daher passt das zu meiner Ausführung, gerade für typische Medien-Anwendungen, wie Live-Streaming (nicht nur) im Heimnetz ist UDP aus grundsätzlichen Erwägungen unter vielen Aspekten TCP überlegen.
EDIT. Zusätzlich spielt neben TCP vs. UDP noch eine Rolle. Sowohl tvheadend als auch enigma2 Receiver streamen puren Transport Stream, ohne Framework/Protokoll außen rum. HLS beispielsweise fragmentiert den TS in Chunks, und hat damit automatisch Aufsetzpunkte. Die tvh/e2 Methode ist da einfach fragiler. Das pure TS ist sicher für Broadcast (über Sat, Kabel, Antenne) sehr gut. Aber da war auch noch Fehlerkorrektur dabei. Im Heimnetzwerk ist das nicht optimal.
Hier noch Varianten für Enigma2-Receiver.
Es sind 4 Bouquets angehängt, ihr braucht nur eines. Für Astra-User optimal sind die Bouquets mit Astra im Dateinamen. Diese werden ohne weitere Klimmzüge direkt Picons und EPG anzeigen, die auch für Astra genutzt werden.
Kabel Deutschland / Vodafone Kabel Nutzer nutzen die Bouquets mit KD im Namen. Wer weder Astra noch KD/Vodafone nutzt wird auf Anhieb kein EPG / keine Picons nutzen können. Hier ist das Setup (z.B. mit EPG-Import) leider etwas beschwerlicher (und führt hier zu weit). Bastler werden antizipieren, dass die Bouquets mit Astra im Namen mit Astra-Empfang kompatible E2-Service-Refs nutzen.
Es gibt jeweils ein Bouquet mit UDP am Ende des Namens. Das ist für ältere E2-Images. Bouquets ohne UDP im Namen funktionieren nur mit relativ aktuellen E2-Images. Theoretisch können die UDP-Bouquets äußerst selten ein Artefakt hervorbringen, funktionieren aber praktisch trotzdem hervorragend. (Technisch: die E2-Images beruhen da auch auf ffmpeg. In Versionen vor 2021 konnte ffmpeg sogenannte Source Specific Mulitcast rtp (SSMC rtp) Streams nicht korrekt behandeln. SSMC UDP (ohne RTP außenrum) geht aber. Da wird ffmpeg bzgl. des Protokolls angelogen. Die Fehlerkorrektur wird in fast allen Fällen auch im puren UDP Stream den Anfang der Transport-Stream Pakete finden. In meinen Tests kamen praktisch keine Fehler vor).
Das E2-Image muss die "Service-App" auf Service-Typ 5002 unterstützen. Meines Wissens tun das zumindest alle aktuellen OE Images.
Zum Installieren. Es gibt verschiedene Wege. Ich zeige, wie das traditionell ohne spezielle Tools bei vielen Images funktionieren sollte, und ohne sich auf etwelche Auto-Bouquet-Installations-Mechanismen von Images zu verlassen. Beispiel Windows.
Windows Explorer starten (z.B. Windows Taste + E), links oben in der Leiste eingeben \\<ip-oder-name-der-box>\etc\enigma2, bei mir beispielsweise \\vusolose\etc\enigma2 (Möglicherweise gibt es da geringfügige Varianten der Samba-Freigaben bei verschiedenen Images).
Das passende der 4 Bouquets entsprechend der Angaben oben wählen und aus diesem Beitrag herunterladen. Umbenennen (im Grunde nach Belieben, aber halt am Ende das .txt wegnehmen, damit der Name mit .tv aufhört). In das im Explorer geöffnete Verzeichnis kopieren.
In dem Verzeichnis, die Datei bouquets.tv suchen, Rechtsklick darauf -> Öffnen mit -> Editor (Falls Editor nicht angeboten wird, ihn finden unter normalerweise c:\Windows\notepad.exe). Nur wer antike nicht mehr supportete Windows-Version nutzt, muss aufpassen und sich Unix-konformen Editor wie Notepad++ besorgen).
In der Datei an offensichtlicher Stelle die Zeile (je nach Benennung der Bouquet-Datei)
#SERVICE 1:7:1:0:0:0:0:0:0:0:FROM BOUQUET "userbouquet.magentatvAstraUDP.tv" ORDER BY bouquet
einfügen und abspeichern. Danach GUI neustarten (oder http://<ip-oder-name-der-box>/web/servicelistreload?mode=0 mit wget, curl oder sogar Browser abrufen)
Anbei eine aktuelle Playlist für Magenta TV für Kodi (oder VLC oder ...). Die Liste funktioniert mit dem Standard IPTV Simple PVR Client von Kodi. Sie basiert auf https://db.iptv.blog/multicastadressliste, hat aber zusätzlich IDs eingetragen, mit denen in Kodi EPG funktioniert (die traditionellen Rytec IDs aus dem Enigma2 Universum, die auch von der Kodinerds IPTV Liste genutzt werden).
Es wird ein Magenta TV Abo und ein Telekom Anschluss benötigt. Funktioniert nicht mit den Magenta TV OTT (over-the-top) Streams, die man auch ohne Telekom Anschluss buchen kann. Funktioniert nicht außerhalb des Heim-Netzes (ohne das man das selbst aktiv weiter streamt).
Es funktionieren auch Teletext und verschiedene Audio-Spuren, auf One beispielsweise oft Original-Ton.
Viele Sender haben eine HD Variante und eine ohne HD (falls man Bandbreite sparen muss). Bei mir funktionieren die HD-Streams allerdings absolut verlässlich auch mit WLAN.
Logos/Picons werden bei euch vermutlich leider nicht auf Anhieb funktionieren - die Liste geht von lokal installierten Logo-Dateien aus. (Namen entsprechen aber typischerweise im Web verwendeten Namen).
Auch angehängt ist eine Variante für tvheadend. Diese unterscheidet sich nur geringfügig von der Kodi-Variante. Tvheadend benötigt übrigens nicht die typische ffmpeg-Pipe für diese Streams, sondern kann sie direkt verarbeiten.
Bei den angehängten Dateien, bitte das .txt am Ende löschen. Wie man den IPTV Simple PVR Client installiert und konfiguriert inkl. Playlist und EPG kann hier im Forum gefunden werden, oder hier: https://kodi.wiki/view/Add-on:PVR_IPTV_Simple_Client
Bei der Shield kenne ich mich nicht aus. Dass nicht nur Auflösung, sondern auch DPI des Displays (beim ersten Gedanken scheinbar überraschend) eine wichtige Roll bei der GUI-Darstellung spielt kennt man auch bei Windows. Beim zweiten Gedanken wird es dann auch mal logisch. Um Schrift gut lesbar zu haben benötigt man eben eine gewisse Ausdehnung. Bei Windows gab es das Schlagwort "High-DPI Aware" (oder eben nicht, bei alten Applikationen).
War krass deutlich, als ich vor vielen Jahren ein Surface Pro 2160 x 1440 bei 12 Zoll bekam. Andere Notebooks derselben Größe hatten oft nur 1/4 der Auflösung. Besonders kompliziert wird es dann wenn man Remote Desktop / Citrix mit so einem Gerät benutzt. Wenn man da bei GUI Elementen Schriften der identischen Auflösung nutzte wie bei dem Low-DPI Display, könnte man nix mehr lesen/grafisch bedienen.
Kodi oder auch Enigma2 Oberflächen (die nicht die echten OS-GUI-APIs nutzen, sondern selbstgestrickte GUI) haben da auch keine DPI-Awareness. Daher oft die GUI-Einstellungen mit niedrigerer Auflösung als der Monitor.
Vermutlich verstehe ich die Problematik nicht - aber wieso kaufst du nicht einfach einen ganz normalen 10 Zoll Rackboden? Die benutze ich in meinem 10 Zoll Rack für "Nicht-Rack-Geräte". DIGITUS Fachboden - 1HE - 10-Zoll - Für Netzwerk-Schrank - 150 mm Tief - Perforiertes Stahl-Blech - Grau: Amazon.de: Computer & Zubehör [Anzeige]
Danke dir für den Link - wieder was gelernt. (Hätte ich eigentlich auch selber drauf kommen können, einfach mal Wikipedia aufzuschlagen. Auch wenn ich "Ferrari-Zähler" als Fachbegriff nicht kannte, findet man es auch über Stromzähler.)
Technisch sollte ja so ein Teil wie das 3EM wohl auch die Blindleistung messen koennen
Tut er auch. Zumindest kann man den "Power-Factor" pf auslesen. Blindleistung = Power*(1-pf)/pf. Bei der Frage ging es mir darum, was da wirklich gemessen wird und was berechnet.
Hatte mich getäuscht mit der Diskrepanz numerische Integration <-> ausgelesener Wert. Hatte nicht berücksichtigt, dass Power zwar in Sekundentakt aktualisiert wird, Energy aber nur jede Minute. Da ich den Vergleich nur 1 h machte, ergab sich (durch die Messdaten - Anfang gleich nach dem Energy-Update, Ende irgendwo mittendrin im Intervall) da 1% Unterschied. Da hatte ich mich gefragt (und tu das immer noch bisschen), was da wirklich gemessen wird. Klar könnte man zeitabhängig mit hoher Abtastrate Strom und Spannung messen und das numerisch korrekt integrieren. Nehme aber eher an, dass sowas wie Veff, Ieff und effektive Phasenverschiebung gemessen wird.
Auch interessant, die Genauigkeit der Haushalts-Stromzähler (typisch A) in Prozent:
| Genauigkeitsklasse | A | B | C |
| mehrphasige Last | 3,5 | 2 | 0,7 |
| einphasige Last bei mehrphasigem Zähler | 4 | 2,5 | 1 |
Somit also gut möglich, dass der Shelly den besseren Wert liefert als der Zähler und die 1,5% Diskrepanz der Werte bei mir sind durch die doch bescheidene Genauigkeit des Stromzählers zu erklären.
Ist mir zufällig im Screenshot aufgefallen: Was ist tvg-rec?
Habe selbst schon Parser zu m3u geschrieben, an tvg-rec kann ich mich nicht erinnern. Bin mir aber schon bewusst, dass da Vieles nicht wirklich standardisiert ist und da manche Anwendungen das nach Belieben selbst definieren. Wenn ich mich recht entsinne nutzt beispielsweise tvheadend tvg-chno, Kodi hingegen tvg-chnum für die Nummerierung der Kanäle. (Und rauszufinden war das praktisch nur über die Quelltext-Analyse). An EXTGRP kann ich mich auch nicht erinnern, aber da kann ich mir schon vorstellen, was es bedeutet. Kenne ich sonst als tag "group-title" in der #EXTINF Zeile.
Vielleicht war Amazon genauso clever wie ich, und hat mal nach "tvg-rec" gegoogelt. Alle Treffer, die ich auf Anhieb fand, sahen nach herunterladbaren Playlists aus - sagen wir mal - legaler Grauzone aus. (Damit will ich keinesfalls implizieren, dass deine App, @M3U IPTV auch zur Grauzone gehört - im Gegenteil).
Da fehlt mir das Equipment.
Nach meiner bescheidenen Erfahrung: Eine einfache Glühbirne kann reichen. Bei der gilt fast exakt Scheinleistung = Wirkleistung. Ich hatte noch eine 60 W Glübirne. Hat wirklich fast exakt die 60 W auf verschiedenen Messgeräten angezeigt (u.a. Shelly Plug S und mehr oder weniger Billig-Zeugs, das ich mal gekauft habe entsprechend Empfehlungen aus ct und anderen hoffentlich verlässlichen Quellen). Meine Tasmota geflashten Geräte lagen typischerweise ohne explizite Kalibrierung vollkommen falsch. Die alte Glühbirne hat es gerichtet ...
