Beiträge von tinub

    vielen dank für die antwort!

    gesucht hab ich schon, doch das passende nicht gefunden ;-)

    geholfen hat die antwort aber trotzdem:
    mein problemsensor war ein AM2302. hersteller stand keiner drauf.

    hab in deiner fusszeile AM2320 gelesen und mich gefragt wie du den am shelly wohl zum laufen gekriegt hast. hatte mir zuerst so ein ding gekauft und dann festgestellt dass der ja I2C ist und somit nicht passt.
    hab nun festgestellt dass ich da bloss ein halbes datenblatt hatte. offensichtlich kann der ja auch 1-wire, was in meinem datenblatt nicht erwähnt war.

    hab den AM2320 nun seit ein paar tagen in betrieb und läuft bislang knitterfrei.

    vielen dank für die hilfe! ;-)

    ich schalte meine shellies ausschliesslich ueber HTTP befehle. demzufolge lese ich mit

    rpc/Switch.GetStatus?id=0

    im JSON jeweils den eintrag

    source "HTTP_in"

    heute nun wollte eines der shellies nicht mehr schalten, und bei der kontrolle mittels browser las ich

    source "loopback"

    was hat das zu bedeuten? woher hat das shelly das letzte schaltkommando gekriegt?

    gibt's eine liste der möglichen einträge fuer source und deren bedeutung?

    an einem 2PM plus verwende ich einen DHT22 sensor, um genau zu sein einen AM2302.

    jeweils nach ein paar stunden kriege ich keine temperatur und feuchtigkeit mehr angezeigt, d.h. das addon scheint den kontakt zum sensor verloren zu haben. abhilfe schafft nur ein unterbrechen der stromversorgung.

    da ich irgendwo gelesen hab dass der pull-up auf der datenleitung zu klein sein kann hab ich zwischen vcc und data mal noch 10k reingehaengt, mit dem erfolg dass der sensor bereits nach wenigen minuten von der anzeige verschwindet.

    hab dann mal stromlos den widerstand auf dem unbeschalteten addon zwischen data und vcc gecheckt und festgestellt dass das so um die 5k sind. muesste also passen. zudem hab ich festgestellt dass im AM2302 zudem ein 10k pull-up verbaut ist. diesen hab ich nun noch rausgenommen so dass extern am shelly nun bloss noch der sensor ohne pullup haengt.

    hat so nun etwa 12h funktioniert, und nun ist der sensor wieder verschwunden.

    hat sonst noch jemand derartige probleme? gibt's eine moeglichkeit diese zu beheben?

    Nachdem was und wie du schreibst gehe ich davon aus dass du vom Fach bist und die Pro3EM korrekt angeschlossen hast.

    bin zwar seit jahren nicht mehr so sehr vom fach, aber ich denke physik ändert sich nicht so rasch ;-)

    und ja, ich gehe davon aus dass ich alles richtig angeschlossen habe, zumal ich mehrere von den dingern installiert hab und überall das gleiche verhalten sehe.

    ohne last testen kann ich die "pro" nicht. mobil hab ich bloss ein 3EM (ohne pro) mit dem ich die ersten tests gemacht hab, und da sieht ja alles bestens aus.

    für die installation hab ich dann die "pro" verwendet, in der annahme dass diese qualitativ besser sind (und ausserdem passten sie besser in die verteilerkasten).

    bislang habe ich das alte 3EM (ohne pro) verwendet. mittels http://<IP>/status krieg ich da die aktuellen messwerte raus.

    wenn ich nun pro phase "current" und "voltage" multipliziere erhalte ich erst mal die scheinleistung und diese multipliziert mit "pf" ergibt die wirkleistung, welche als "power" ausgelesen wird. soweit alles paletti.

    nun habe ich kürzlich 2 pro 3EM installiert, und alles sieht etwas anders aus:

    mittels http://<IP>/rpc/EM.GetStatus?id=0 liefert mir das pro 3EM die aktuellen leistungsdaten.

    wenn ich nun "current" mit "voltage" multipliziere, so erhalte ich die scheinleistung, welche korrekt als "aprt_power" ausgegeben wird. soweit alles ok.

    ich würde nun davon ausgehen dass ich diesen wert mit "pf" multiplizieren kann und dies den wert ergibt, welcher as "act_power" ausgegeben wird.

    weit gefehlt!

    ich hab einzelne werte-sets bei welchen durchaus passende werte dabei sind, zumindest jeweils für eine phase. in der regel liegt der aus "aprt_power" * "pf" ermittelte wert aber bis zu 20% neben dem wert von "act_power", dies ganz abgesehen davon dass der "pf" wert meist negativ ist.

    ganz übel wir's dann aber bei kleinen leistungen. ok, das ist nicht wirklich relevant, aber bloss der vollständigkeit halber:

    hier wird "pf" stets mit dem wert 1 angegeben (komischerweise ein positiver wert), wobei "aprt_power" aber ein vielfaches von "act_power" beträgt. in so einem fall müsste "pf" doch eigentlich nahe bei 0 liegen.

    ist die firmware des pro 3EM ganz einfach noch nicht ausgereift (ich verwende 0.14.1) und kann ich davon ausgehen dass das ding über die zeit noch besser wird?

    oder mach ich einen überlegungsfehler und alles was ich da sehe ist korrekt? :?:

    falls letzteres zutrifft, wo finde ich hierzu detailiertere infos?

    mittels http://<IP>/rpc/EMData.GetData?id=0&ts=<TS>&minutes=1 kann ich aus dem shelly ja die history mit minutenauflösung rauslesen.

    bei der interpretation der daten tue ich mich allerdings etwas schwer.

    die energie wird ja in kWh/min. wenn ich die werte somit mit 60min/h multipiziere erhalte ich die durchschnittsleistung innerhalb des ausgelesenen intervalls.

    nun aber zu den "keys" innerhalb des datensatzes:

    der prefix "a_", "b_" und "c_" bezeichnet die phase.

    ich gehe davon aus dass "total_act_power" die über eine minute aufsummierte wirkenergie bezeichnet. multipliziert mit 60 krieg ich somit die durchschnittliche wirkleistung. :?:

    was aber ist nun "fund_act_energy"? mit diesem begriff weiss ich nix anzufangen. wie übersetzt man dies ins deutsche und was ist das?

    komischerweise liegt dieser wert mal etwas über, mal etwas unter "total_act_power". :?:

    die beiden werte "total_act_ret power" und "fund_act_ret_energy" erfassen dann wohl das was an den versorger zurück geht, sobald die PV anlage in betrieb ist.

    mit "total_act_power" und "total_act_ret power" krieg ich somit die werte von bezug und einspeisung getrennt angezeigt. ist das korrekt :?:

    schon mal vielen dank für sachdienliche hinweise!