Beiträge von der.fpg

moin,

...ich habe seit einigen Tagen Lücken in der Übertragung der Leistungs-Messwerte. In unregelmässigen Abständen bricht die Übertragung für 30sec. bis 5min. ab. Das Gerät ist über das LAN angebunden.

WLAN machte zuerst Probleme, jetzt ist auch die LAN-Verbindung lückenhaft. Ein Reset hilft anfangs scheinbar... dann dauert es nur ein bis zwei Tage, bis die Ausfälle wieder zunehmen.

...was ist da los ? Defekt ?

Firmware: 1.7.0

lg

Moin,

... dran gedacht habe ich schon, zunächst wollte ich aber einen lösungsweg im forum beschreiben (der hinweis auf die mangelhafte softwarequalität war eine reaktion auf den vorpost bzgl. einstellmöglichkeiten )

lg vom fpg

Moin,

.... das ändert jedoch nichts an der bedenklichen softwarequalität. Generell sollten angebotene funktionen auch sicher funktionieren ... und gerade im smarthome muss man sich auf solche kleinigkeiten verlassen können. Wlan-geräte bieten gern genommene möglichkeiten, ein netzwerk zu entern. Wenn dann die software nicht in der lage ist, grundlegende sicherheitsanforderungen einzuhalten, wird es sehr unterhaltsam.

lg vom fpg

moin,

...die lokale router-adresse für DNS macht auch nicht die o.g. probleme (unter v 0.13.0) ...auch die hardware ist in diesem fall nicht das problem. Es ist der pre-beta-zustand der software zum ausgelieferten produkt. Wenn grundsätzliche einstellungen nicht zuverlässig abschaltbar sind, ist das murks. Kunden ohne entsprechende kenntnisse haben sich dann kernschrott gekauft den sie bestenfalls wieder an den verkäufer zurückschicken können.

So wie es aussieht, haben die probleme beim update ihre ursache in persistenten einträgen der netzwerkkonfiguration im shelly-device.

- Reset (soft und hard) haben keinen einfluss auf diese einträge . Da steckte ggf. absicht hinter, damit ein restart klappt, wenn das device mal stromlos war.... aber hier liegt auch der hund begraben.... !!

- wurde einmal für den DNS ein wert eingegeben, bleibt dieser auch aktiv wenn die netzwerkeinstellungen wieder auf DHCP gestellt werden. Das device verwendet weiterhin die zuvor eingegebenen werte und ignoriert die vom DHCP-server gelieferten parameter.

Um die notwendigen updates > version 0.13.0 zu bekommen, sollte man folgendes versuchen:

- über die web-gui des devices im WLAN-menü alle werte zunächst auf die vom DHCP-server des eigenen netzes gelieferten werte setzen (eine ip aus dem privat-range wählen, netzmaske entsprechend setzen, gateway und DNS passend auf die routeradresse zeigen lassen)

z.b. in einem 192.168.1.xxx - netz --> device-IP: 192.168.1.105, netz-maske: 255.255.255.0, gateway: 192.168.1.1, DNS:192.168.1.1

- speichern

- dann alles wieder auf DHCP zurücksetzen

- update starten

ich habe ein segmentiertes netz mit jeweils eigenen adressräumen. Die oben geschilderte prozedur habe ich im ersten segment hinter dem primären router zum internet durchgeführt.

Zeitsynchronisation

- es sind scheinbar auch die einstellungen für NTP von diesem verhalten in 0.13.0 betroffen (hier könnte es probleme mit zeitkritischen anwendungen auf dem device geben, habe ich aber nicht getestet).

Ob und wie ein eigener NTP-server eingebunden werden kann, habe ich noch nicht herausfinden können.

lg vom fpg

moin,

...ich auch... aber mit dem lokalen DNS haben die shellies durchweg probleme ...

der fpg

moin,

... wie vermutet bzw. auch in den scans und logfiles zu sehen.... in der version 0.13.0 werden einige register nicht gelöscht, wenn z.b. von fixen netzwerkeinstellungen wieder auf DHCP umgeschaltet wird... soweit nicht schlimm...aaaaber wenn ich DHCP nutze, dann sollte auch der vom server übermittelte wert für DNS genutzt werden und nicht der aus den fixen einstellungen. Das scheint auch die einstellungen für NTP zu betreffen.

Für alle, die einen eigenen DNS in ihrem netz bzw. feste IP-adressen verwenden, ein no go !

... nachdem ich alles mehrfach über soft- und hard-reset versucht habe, jedoch die besagten einstellungen dagegen resistent waren, habe ich dann die DNS-einträge manuell auf die routeradresse umgelegt.

Das update hat geklappt und in der cloud sind die dinger auch zu sehen.... nun werde ich die intensiv beschnüffeln, da es auch mit der neuen firmware eigenartige lustigkeiten gibt

lg vom fpg

Moin,

... nun gut... aber die lösung für das obige problem via autorisiertem update ist noch nicht gefunden. Im falle der v. 0.13.0 auf dem ppS ist ja allem anschein nach die grundsätzliche konfigurationsmöglichkeit der netzwerkeinstellungen unsicher bis unbrauchbar. Drei möglichkeiten:

- entsorgen des device

- irgendwie updaten (wobei der punkt "custom firmware" von shelly ausdrücklich mit einer verzichtserklärung verbunden )

- fremdsoftware, keine zulassung mehr (software ist teil des produkts)

Bleibt noch der echte hard-reset über den esp... aber der himmelt evt. auch das os...

lg vom fpg

Moin,

... wenn du beweisen kannst, dass die von dir eingesetzte software nicht ursächlich für den fehler war (überlasterkennung, schutzabwurf usw.), könnte es möglich sein. Der hersteller der ursprungslösung wird aber dagegenhalten und zurecht den standpunkt der unautorisierten manipulation durch laien vertreten.

Lg vom fpg

Moin,

das update über die web-gui funktioniert auch nach mehreren resets bzw. factory-resets nicht. Zum testen auf andere ursachen, wie firmware-probleme, habe ich in verschiedenen netzwerksegmenten meines home-net getestet. Dabei ist mir aufgefallen, dass offensichtlich nicht alle werte beim firmware-reset zurückgesetzt werden. Betroffen sind einstellungen zum dns und zum time-service. Es sieht so aus, dass die devices einfach nicht das repository mit den updates finden und das aufgrund einmal getätigter eingaben für feste adressierungen... auch wenn diese deaktiviert, gelöscht oder über einen factory-reset längst unwirksam sein sollten. Für mich ein zeichen schlechter softwarequalität. Ich würde jedem abraten, derartige geräte in einem schlecht gesicherten netz zu betreiben... wenn ich noch zeit oder lust aufbringe, kann ich mal auf den datenverkehr der shellies lauschen... aber eigentlich reicht schon der oberflächliche befund als ausschlusskriterium für das zeugs, da grundsätzliche funktionen nicht zu sicheren ergebnissen führen. Für ein produkt, dass eigentlich für den normalen verbraucher konzipiert wurde, ist es meines dafürhaltens eher ungeeignet. Die software/firmware hat bestenfalls beta-qualität und die nutzer sind die tester (nur unbezahlt, bzw. finanzieren durch den kauf sogar die produktisierung bei shelly, crowsfunding 2.0 )...

...der umstieg auf tasmota scheint ein ausweg zu sein, hat aber ebenfalls einen haken: alle zulassungsrelevanten zertifikate werden ungültig (ce, vde ....). Wer soetwas verantwortlich einsetzt muss im schadensfall dafür gerade stehen.

Lg vom fpg

Moin,

...zunächst bügel ich da mal tasmota drauf.... evt. läuft das ja besser als das shelly-geraffel...

lg vom fpg

Moin,

...nach diversen versuchen nehme ich die shellies aus meinem netz und hau sie zum e-schrott.... diese dämlichen plusplugS weigern sich beständig gegen alle update-anstrengungen. Firmware 0.13.0 und nichts anderes scheint aktueller zu sein.

Der factory-reset scheint nicht alle daten zu löschen... das logging zeigt munter zugriffszugriffsversuche auf meinen internen zeitserver an. Der server heisst allerdings nicht "time.google.com" ....

lg vom fpg

moin,

... da scheint man sich nicht viel mühe mit der software zu geben

...MQTT ging dann jetzt wieder... ursache war tls ... wtf ! Der rest geht aber noch immer nicht....

der fpg

moin,

mein 1PM mini Gen3 ist im lokalen Netz zu sehen.... soweit so gut... auch liefert sein Web-interface die Daten des elektrischen Anschlusses, reboot usw. alles da... nur ist das Ding weder in der Lage, seine Daten an die Cloud noch an meinen lokalen Home Assi zu schicken... selbst MQTT liefert nichts an meinen FHEM noch meinen Home Assistant.

Das cloud-ui erkennt den Mini, behauptet aber konsequent, dass die Verbindung noch ausstehend ist (mein shelly 3EM wird ebenfalls so angezeigt, liefert aber seine Daten brav an meine Home Assistant und FHEM Instanzen).

FW-ID vom Mini: 20231121-110955/1.1.99-minig3prod1-ga898543

FW-ID vom 3EM: 20220415-105853/v1.11.7-25-gb3b096857-v1.11.7-3em

... was ist los mit den shelly's ?

lg vom fpg

moin,

... hm... so ginge das doch ... es geht ja auch so ein wenig um "best practice".... ich habe z.b. das ganze mal mit dem vorhandenem kram versucht... da wird es doch recht unübersichtlich

die breiten linien ergeben sich durch die anzahl der messungen pro zeiteinheit... die schwanken ja doch erheblich... und bei der auflösung der zeitleistenansicht gibt es dann diesen breiten "strich" ..

was die ladezeit der grafik angeht... angesichts der datenmenge... unterirdisch

mich würde es natürlich interessieren, wie ihr das angehen würdet. Meines war ja nur ein voschlag.

grüsslinge vom fpg

moin Kai,

whow... danke für die mühe ... ich bräuchte eigentlich (didaktischer ansatz ) eine art lösungsstrategie, also hilfe beim design der/einer lösung am konkreten fall.

- nur die gewünschten readings nutzen

- nur die gewünschten readings loggen

- nur die gewünschten readings anzeigen

- anzeige der aktuellen werte im numerischen format

- diagramme der lastwerte (durchlaufend)

- tageswerte der verbräuche als diagramm (durchlaufend)

der output vom shelly beinhaltet neben den reinen messwerten von strom und spannung auch die summen der einzelleiter sowie eine summe a toto, damit müsste man nichts im fhem halten, bis auf die letzten übertragenen werte.

ich hatte zunächst an userReadings gedacht, die ich auf die jeweiligen leiter (als devices, also L1 ist ein device, L2 ist eines und L3 ebenfalls) verteile. Meine idee dabei war, dass ich dann leichter das ui gestalten kann (hab ich bei meinen anderen devices so gemacht). Auch könnte man so leichter scalieren bzw. eigenschaften hinzufügen.

die reste der letzten versuche habe ich alle gelöscht und das unangetastete template wieder verwendet. Alles ist soweit wieder in ordnung.

idee mit den leiter-devices:

#device L1:

emeter_0_current --> 0.66 --> A (Strom, einheit Ampere)

//emeter_0_energy 146 --> kJ (Energie, vermutlich in kilojoule gemessen, kann ignoriert werden)

//emeter_0_energy_total 1255 --> kJ (Energie gesamt, vermutlich in kilojoule gemessen, kann ignoriert werden)

emeter_0_kWh --> 3.76 --> kWh ( Arbeitsleistung, einheit kilowattstunden)

emeter_0_pf 0.98 --> ohne einheit (power factor = leistungsfaktor bzw. wirkleistungsfaktor)

emeter_0_power --> 143.65 --> W ( Leistung, einheit W)

//emeter_0_returned_energy --> 0 --> W (falls mal einspeisung stattfindet, kann ignoriert werden)

//emeter_0_total --> 3758.9 --> Wh ( Gesamte Leistung, warum auch immer in Wattstunden statt in kWh...)

//emeter_0_total_returned --> 0.0 --> Wh (Gesamte Leistung, falls mal einspeisung stattfindet, kann ignoriert werden)

emeter_0_voltage --> 224.39 --> V (Spannung, einheit Volt)

#device L2:

emeter_1_current

//emeter_1_energy

//emeter_1_energy_total

emeter_1_kWh

emeter_1_pf

emeter_1_power

//emeter_1_returned_energy

//emeter_1_total

//emeter_1_total_returned

emeter_1_voltage

#device L3:

emeter_2_current

//emeter_2_energy

//emeter_2_energy_total

emeter_2_kWh

emeter_2_pf

emeter_2_power

//emeter_2_returned_energy

//emeter_2_total

//emeter_2_total_returned

emeter_2_voltage

#device Summe L1L2L3:

total_power --> 153.50 --> kWh (Arbeitsleistung aller "phasen", einheit kilowattstunden)

emeter_0_kWh

emeter_1_kWh

emeter_2_kWh

...könnte man das so machen ?

- die neuen devices (L1,L2,L3, Summe L1L2L3) anlegen

- dann die readings zuordnen

- dann das ui basteln

- dann die diagramme generieren

- log-files minimieren

gruss vom fpg

moin,

ok... dann war das gemeint:

grüsslinge vom fpg

moin,

meinst du die readings ?

die aktuelle konfiguration stammt aus dem template "Shelly3em"

das scheint die gesamtleistung aus verbrauchter und eingespeister leistung zu berechnen.... ich hatte im verlaufe meiner versuche alle werte mit "_returned_ " entfernt, was jetzt zum ausfall der summenbildung führt ...

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/0/power:.* emeter_0_power

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/0/pf:.* emeter_0_pf

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/0/current:.* emeter_0_current

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/0/voltage:.* emeter_0_voltage

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/0/total:.* emeter_0_total

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/0/total_returned:.* emeter_0_total_returned

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/1/power:.* emeter_1_power

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/1/pf:.* emeter_1_pf

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/1/current:.* emeter_1_current

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/1/voltage:.* emeter_1_voltage

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/1/total:.* emeter_1_total

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/1/total_returned:.* emeter_1_total_returned

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/2/power:.* emeter_2_power

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/2/pf:.* emeter_2_pf

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/2/current:.* emeter_2_current

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/2/voltage:.* emeter_2_voltage

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/2/total:.* emeter_2_total

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/2/total_returned:.* emeter_2_total_returned

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/relay/0:.* relay_0

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/0/energy:.* emeter_0_energy

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/0/returned_energy:.* emeter_0_returned_energy

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/1/energy:.* emeter_1_energy

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/1/returned_energy:.* emeter_1_returned_energy

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/2/energy:.* emeter_2_energy

shellyem3_485519C977BA:shellies/shellyem3-485519C977BA/emeter/2/returned_energy:.* emeter_2_returned_energy

grüsslinge vom fpg

moin,

hay kai ... bei mir spielen aktuell nur die messwerte der drei aussenleiter/"phasen" eine rolle. Hintergrund ist, festzustellen

a. wie hoch die last auf dem jeweiligen leiter is

b. was der leiterbezogene verbrauch ist

c. die summe der verbräuche

"a." ist interessant für den einsatz einer stecker-photovoltaik. ich denke an eine lastgeführte einspeisung von überschussleistung... also ggf. mehr, als eigentlich zugelassen ... dazu eignet sich dann eine gezielte einspeisung auf den gierigsten stromkreis. Zudem kann der tageslauf interessante aufschlüsse liefern.

"b." und "c." liefern dann noch werte, die einsparpotentiale aufzeigen können.

ein ergebnis habe ich schon und bin doch überrascht: die grundlast meines hauses ist erfreulich niedrig, dafür dass hier jede menge "spielkram" am netz hängt (diverse standby geräte, drei bis vier raspis, ein nas usw., der kühli, die heizungspumpe/n, ladegeräte usw.). Toll ist auch der unterschied zwischen led beleuchtung und heizballons ... die lampe über dem esstisch verbrät soviel strom wie alle weiteren lampen im erdgeschoss zusammen. Klar, aber wenn man es dann als messwert sieht, wirkt das schon ganz anders.

grüsslinge vom fpg

moin,

...ja klar hilft das ... das loggin habe ich mittlerweile im griff. Es ist echt krass, was der em3 an daten raushaut. Jetzt bastel ich mir zunäxxt mal eine adäquate anzeige der verbrauchswerte. Was da gerade läuft hat einen bug... der akkumuliert weder die aussenleiter noch deren summe :-/ ... aber das bekomme ich auch noch hin ... der rest ging ja auch

gruss vom fpg

moin Helmut, moin supernova1963,

...hab ich gesehen, danke ! Ich habe so mein problem mit dem umgang im fhem-forum. es ist zwar wirklich sehr kompetent, aber es leidet etwas unter einer gewissen arroganz

...ich mag als naturwissenschaftler und senior it consultant keine geheimwissenschaften... meine lebenszeit ist zu begrenzt, um mich mit allem in aller notwendigen tiefe zu beschäftigen.

also: danke für die hilfestellung. Ich glaube, man lernt an einer gemeinsamen lösungsfindung immer mehr als beim doku-lesen !

Die obige schilderung hilft gut weiter (mqtt kenne ich noch aus den späten 90'er, kam im rahmen eines entwicklungsprojekts 2017.. nbiot.. wieder damit in touch )

Ich war etwas verwirrt, als mir im fhem-forum eine etwas missverständlich erklärung zum mqtt2-server gegeben wurde.

...ach so... der datentransfer vom em3 zum fhem-raspi funktioniert, es geht mir nur um die datenmengenminimierung... momentan versuche ich es mit "event-on-change-reading"

beste grüsse vom fpg