Bei mir auf Server 38 scheint das Problem seit ca. 10 Uhr auch behoben zu sein.
Vielen Dank für die Info und viele Grüße
Wolfgang
Beiträge von WolfPetri
-
-
Vielen Dank. Damit bin ich auf Server 38.
-
Auch bei mir seit gestern 14.00 - 15.00 Uhr gleiches Problem mit 3EM und 1PM. Statistikwerte deutlich geringer als Normal. Normalwerte um 300-400 W.
Anbei ein Screenshot von der 3EM. Aktuelle Werte stimmen, so dass die Werte in HA auch richtig sind.
Also denke ich, dass das ein Shelly Cloud Problem ist.
Wo erkennt man, auf welchem Server man sich befindet ? Würde mich freuen, wenn es dafür eine Erklärung gibt.
-
Für alle diejenigen, die das Thema interessiert. Ich habe eine Lösung gefunden :
Ich habe einen Shelly 1PM im Zählerkasten zwischen den Stromkreis für die Heizung geschalten. Da dieser natürlich den gesamten Verbrauch der Heizung , auch wenn nur die Pumpen laufen. misst, ich aber für die Betriebsstunden des Brenners, nur die Zeit , wo der Brenner an ist, messen will, habe ich einen Helfer als Schwellenwertsensor (binary_sensor.bh_hz_schalter)errichtet. Dieser wirkt als virtueller Schalter. Befindet er sich innerhalb der Grenzen, schaltet er an, sonst aus.
Als Untergrenze habe ich 100 W eingestellt. Das ist ausreichend, wenn nur die Pumpen laufen. Schaltet der Brenner ein, verbrauche ich ca. 180 W . Der Schalter (Schwellenwert) schaltet ein und wenn der Verbrauch unter 100 W geht, wieder aus.
Die Zeit, die dieser virtuelle Schalter "on" ist, ermittle ich folgendermaßen:
# Beispiel configuration.yaml: Betriebsstundenzähler (hatte ich hier in einem Forum entdeckt)
sensor:
- platform: history_stats
name: on_time_hz_bhw
entity_id: binary_sensor.bh_hz_schalter
state: 'on'
type: time
start: '{{ 0 }}'
end: '{{ now() }}'
# Diese Sensoren stehen dann bereit
utility_meter:
daily_on_time_hz_bhw:
source: sensor.on_time_hz_bhw
cycle: daily
weekly_on_time_hz_bhw:
source: sensor.on_time_hz_bhw
cycle: weekly
monthly_on_time_hz_bhw:
source: sensor.on_time_hz_bhw
cycle: monthly
quarterly_time_hz_bhw:
source: sensor.on_time_hz_bhw
cycle: quarterly
yearly_on_time_hz_bhw:
source: sensor.on_time_hz_bhw
cycle: yearly
So binde ich den Wert des hochlaufenden Zählers ein:
- sensor:
name: Hz_Bh_fortlaufend
unique_id: Hz_Bh_fortlaufend
state: >-
{{ (max(0,states('sensor.yearly_on_time_hz_bhw')|float(0)))|round(2) }}
state_class: total_increasing
unit_of_measurement: 'Bh'
....und werte das ganze dann in meinem Dashboard aus
Habe das jetzt eine Weile laufen und stimmt mit dem Betriebsstundenzähler an der Heizung überein. Das erspart das Ablesen im Keller und die entsprechenden Auswertungen über Betriebstunden, Ölverbrauch usw. könnt ihr nun im Homeassistant vornehmen.
Das ist nur eine Lösung und kann jemand natürlich auf ganz andere Weise gelöst haben.
-
Hallo in die Runde
Ich habe Folgendes vor und erbitte dazu Eure Hilfe:
Zur Erfassung der Betriebsstunden meiner Ölheizung möchte ich einen Shelly 1PM an der Sicherung der Heizanlage vorschalten und kann dann damit die elektrische Leistung der kompletten Heizanlage messen, Außerdem möchte ich die Zeit, die der Brenner läuft zur Erfassung der Betriebsstunden erfassen. Nun könnte ich die Zeit, in welcher durch den Shelly Strom fließt, als Zeitbasis erfassen, aber da über den gleichen Stromkreis ja auch die Pumpen laufen, geht das nicht so, sondern ich müsste auch gleichzeitig z:B. eine Leistung angeben, ab welcher gezählt wird (wenn der Brenner einschaltet und wieder ausschaltet).
Nun habe ich hier im Forum eine Lösung für einen Betriebsstundenzähler gefunden und weiß aber nicht, wie ich diese Lösung anpassen müsste, um nicht den Schalter (state:"on") als trigger zu nehmen , sondern eben eine Leistung von grösser x.
Vielleicht gibt es aber auch einen anderen Ansatz.
Die gefundene Lösung war folgende :
# Example configuration.yaml Betriebsstundenzähler
sensor:
- platform: history_stats
name: on_time_lg_tv
entity_id: shelly1PM_SCHALTER (soll dann "shelly_1PM_Power§ sein)
state: 'on' (state: Power> x Watt)
type: time
start: '{{ 0 }}'
end: '{{ now() }}'
utility_meter:
daily_on_lg_tv:
source: sensor.on_time_lg_tv
cycle: daily
weekly_on_lg_tv:
source: sensor.on_time_lg_tv
cycle: weekly
monthly_on_lg_tv:
source: sensor.on_time_lg_tv
cycle: monthly
quarterly_on_lg_tv:
source: sensor.on_time_lg_tv
cycle: quarterly
yearly_on_lg_tv:
source: sensor.on_time_lg_tv
cycle: yearly
Ich freue mich über jede Anregung zur Lösung des Problems.
-
Also ich habe nochmal nach dem Fehler gegoogelt. Das ist wahrscheinlich ein Hardware (NUC) - Fehler. Da muss ich an anderer Stelle nachfragen, gehört also nicht in das HA-Forum.
-
Hallo in die Runde
Bei mir taucht seit einigen Tagen, ohne dass ich weiss, bei welcher Aktion, die in Bild dargestellte Fehlermeldung im HAOS (Intel NUC) auf. Diese wird ständig (alle 5 Sek) wiederholt, so dass man kaum noch einen Befehl auf OS Ebene eingeben kann.
Herunterfahren und Neustarten HAOS bringt nichts. Auch Neustart Bluetooth am Rechner bringt nichts.
Der Homeassistant läuft trotzdem ohne erkennbare Fehler.
Vielleicht kann mir jemand helfen, dieses Problem abzustellen.
-
Ja, es ging um Deinen Ansatz einer Mischer-Steuerung. Also den Dimmer immer mit up oder down so bewegen , dass sich der Strom-Überschuss um den 0-Punkt bewegt.
Ich würde das Thema dann im damals benutzten Forum fortführen.
-
So, nachdem ich alles probiert habe, was ich Euren Antworten entnehmen konnte, aber leider keine Veränderung bewirken konnte, habe ich das HassiO
Heute Abend neu auf den NUC aufgesetzt. Nach dem Neustart funktionierte alles wieder. Die configuration.yaml und die automation.yaml hatte ich mir ja in ein Textfile gespeichert, so dass ich im Wesentlichen nur die Ansichten neu gestalten musste. Werde mich gleich morgen mit dem Thema Backup beschäftigen. Das soll mir nicht noch mal passieren.
Ich bedanke mich ganz herzlich für Eure Hilfestellungen. Sicher hättet ihr hier bei mir vor Ort in solchen Netzwerkproblemen eine andere Lösung gefunden, aber ich verstehe davon nicht viel.
Nochmals vielen Dank und viele Grüße
Wolfgang
Hallo Schubbie
Wenn alles wieder läuft, würde ich gern nochmal auf Deine Lösung mit Node-Red zurückkommen, weil ich denke, dass sie genauer ist. Ich hatte es ja grade zum Laufen gebracht.
Muss ich natürlich noch einmal installieren. Ich würde mich später gerne bei Dir melden. Vielleicht per PN ?
VG Wolfgang
-
Oh, das habe ich nicht gesehen.
Bin jetzt bis Abend unterwegs. Probiere es danach gleich nochmal.
-
Nein, eigentlich nicht.
-
Ich habe jetzt das Netzwerk nochmals gestestet (das hatte ich ganz beim Auftauchen des Fehlers gleich zuerst schon einmal gemacht).
Internet funktioniert am angesteckten Laptop über LAN einwandfrei.
Bei einem "core check" kommt eine lange Fehlermeldung
"Cant execute command: 500 cerver error for http + docker : //localhost/v1.41/images/create?tag -latest &from image=ghcr.io/2 Fgeneric-x86-64-homeassistant : Internal Server Error / (Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io: Temporarily failure in name resolution")
-
Also hier ist wahrscheinlich doch etwas am Netzwerk kaputt.
Habe grade "core restart" gemacht und auch eine Fehlermeldung erhalten
" post "http://supervisor/core/restart": context deadline exceeded ( Client.Timeout exceeded weile awaiting headers)
Ich teste jetzt erstmal das Netzwerk durch. Vielen Dank für die Hilfe bis hierher.
-
Ja, funktioniert nicht
-
Die LAN Buchse blinkt grün. Ich hatte auch beim Start von Hassio einige Meldungen gesehen, die die LAN Verbindung als OK anzeigen.
Allerdings sieht man auch diese Meldungen so kurz, dass man nicht viel erkennt. Aber ich werde morgen nochmal einen Test mit einem anderen Gerät machen, damit wir das 100 %-ig ausschließen können. Habe grade noch gesucht, ob es noch andere Befehle auf der cli-Ebene gibt, die das eindeutig anzeigen, aber nichts gefunden. Also das checke ich morgen nochmal, könnte ja ein Problem im NUC sein.
-
Leider passiert nichts, wenn ich das LAN Kabel ziehe. Ungeänderte Network Info.
Also bin ich wohl doch irgendwo im Nirwana.
-
Also erst einmal herzlichen Dank für Eure Beiträge dazu.
Also hier nochmal die Situation.
Nach einem (wahrscheinlichen) Fehler meinerseits beim Einrichten der Internetverbindung zu HA mit DuckDNS znd Nginx gibt es keine Verbindung mehr zur HA Oberfläche.
An meinem NUC wird HA problemlos gestartet und meldet sich bereit, aber auf dem PC kann ich keine Verbindung herstellen. Der NUC hat keine zweite Netzwerkkarte. Ich habe mal die Network Info angeschaut, da stehen nur 172. er Adressen, die helfen auch nicht weiter. In der Fritzbox ist die Verbindung nur ausgegraut angezeigt, aber nicht aktiv und kann auch nicht gestartet werden.
Ich habe mittlerweile die DuckDNS Adresse wieder gelöscht und würde das auch nicht wieder benutzen, da nehme ich lieber VPN. Aber soweit bin ich noch nicht.
Ich würde es morgen nochmal mit dem Port 80 und mit dem Gastsystem von SSH versuchen.
Wenn da auch nichts geht, glaube ich langsam, dass ich nicht umhin komme,
Hassio neu aufzusetzen.
-
Nein, ich habe HA direkt auf den NUC installiert. Das CLI wird auch anstandslos gestartet. Wenn man hier auf dieser Ebene die Netzwerkeinstellungen von HA bearbeiten könnte.
Auf der Fritzbox ist Homeassistant als ungenutzte Verbindung da. Kann sie nach wie vor nicht starten.
Habe auch Backup restore [slug] gemacht zum 26.6. . Hat Erfolg zurückgemeldet, aber geändert hat sich nichts.
-
Das habe ich schon probiert. Geht leider nicht. Aber ich glaube auch, dass es damit zu tun hat. Ich werde am NUC mal das Backup restore probieren.
-
Ja, ich habe es im Browser mit der Adresse mit Port 8123 und 443 auch versucht.
Auch mit der DuckDNS Adresse. Das Gerät ist nicht mehr in der Fritz Box zu finden 🙄
Aber ich habe grade festgestellt, daß ich doch Backups gemacht habe.
Habe auf dem NUC die Befehlszeile "ha backups" eingegeben und da kam ne Liste. Leider kann ich das scrollen nicht anhalten und die letzten
stehen ganz oben. Ich sehe sie nicht mehr. Ansonsten würde ich es mit Backup restore [... ???] versuchen.
Was genau müsste denn dort eingegeben werden?