apower, aenergy.total, temperature.tC, voltage alle 2s in eine InfluxDB den vom Shelly zuletzt über MQTT Veröffentlichten Wert. Für den Ertrag habe ich aber nur auf aenergy geschaut, denke da wird vom Shelly selbst häufiger abgetastet als wenn man es selbst über apower berechnen würde.
Der EcoMode lässt bei mir den gemessenen Spannungswert um 3-4V sinken (bitte keine Grundsatzdiskussion, ich weiß die schwankt permanent). Hatte aber keinen Einfluss auf den Messfehler, ob ein oder aus.
...
>3 neue installiert jetzt sind die Werte wieder im Rahmen
die kamen dann schon mit der korrekten (letzten) Firmware?
Kann nicht mehr genau sagen welche Version drauf war aber keine aktuelle v1.2x, update war in mehreren Schritten -> 1.3.x -> 1.4x
Laut DTU waren es auf der DC Seite etwa 201W und auf der AC 192W, deutet eher darauf das die 192Wh der AC Seite entsprechen und die Verlustleistung des WR bereits berücksichtigt...
Laut Shelly sind die Geräte defekt. Ich wunder mich zwar immer noch wie 3 Geräte just nach dem Update plötzlich defekt sind, vielleicht hat es ja etwas an der Kalibrierung zerschossen aber sei es drum. 3 neue installiert jetzt sind die Werte wieder im Rahmen.
Laut DTU 192Wh nach dem für 1h 200W DC eingespeist wurde, laut Shelly 183,72Wh -> Jetzt also etwa 4,5% zu niedrig, wobei ich dabei nicht sagen kann wer nun "richtig", näher dran liegt.
Für mich mit dem Austausch erledigt.
Hast du mal ein Ticket beim Hersteller erstellt?
Meine liefern für mich plausibel Werte
Habe ich, aber erst kürzlich, in der Vergangenheit haben sie auch im Forum mitgelesen und geantwortet.
Danke für die Rückmeldung, ist es bei dir auch der Gen2 und wird er von einem MikroWechselrichter gefüttert? Vielleicht macht die "Last" da ja einen Unterschied.
Es macht keinen unterschied ob ich die Werte im mittel betrachte, oder jeweils nur einen Wert pro 1s, 10s, 1min, 5min es kommt immer das gleich raus.
Auch die Werte in der Cloud zeigen das gleiche.
Vielleicht lässt es sich über den Verbrauch ja leichter nachzuvollziehen.
Die DTU ist vom Wechselrichter Hersteller zeigt 192Wh nach dem für 1h 200W DC eingespeist wurden. Shelly inkl. Cloud zeigt 223Wh.
Da ist keine Auswertung dazwischen, es wir so vom Shelly erfasst und übermittelt und wieder sind es etwa 17% zu viel.
Den restlichen Phrasen kann ich leider nichts entnehmen.
wünsche besinnliche Feiertage
Welche Peaks meinst du, die Sonne scheint halt nicht immer gleich. Das kann man doch nicht einfach alles wegbügeln.
Da steckt je nach Intervall natürlich schon eine Glättung durch den Mittelwert drin. Der Trend, die Abweichung bleibt aber. Auch im live Vergleich ist es etwa der gleiche Fehler.
Wie du schreibt auf dem mittleren Bild nahe 0, das ist VORHER, da war es voll im Rahmen, mehr Erwarte ich nicht.
Hier mal 200W DC fix in den Inverter, der macht daraus bei knapp 95,xx% Wirkungsgrad etwa 192W AC.
Messung Hoymiles 192W, Messung Shelly 224W das sind wieder etwa 17% zu viel.
Blau die Abweichung, kein Mittelwert:
Ich setze jetzt nochmal alles zurück, hatte in nach den letzten Updates nicht nochmal gemacht, man weiß ja nie.
Edit: FactoryReset hat leider nichts geändert liegt weiter daneben:
thgoebel Hab mich nur über die Verallgemeinerung geärgert, bzw. eher noch dass dieses Thema immer noch ungelöst ist.
DIYROLLY Ich wäre froh wenn noch etwas dazwischen wäre worauf ich Einfluss habe. Es werden direkt die Werte vom Shelly hergenommen "apower" und "aenergy" und startet genau nach dem Firmware update.
Laut INV liegt der Leistungfaktor bei ~1,000 und die Blindleistung schwankt zwischen 0 und 0,3 var.
Hab mal aus der Historie rausgesucht, man sieht vor dem Update waren die Werte sehr nah beieinander und schlagartig mit dem Update gehen sie auseinander.
In blau der unterschied zwischen Shelly und INV über 1 Jahr, man sieht recht deutlich das es nach dem Update im Feb. auseinander läuft.
Vor dem Update recht dicht beieinander:
Nach dem Update, etwa 17-19% Abweichung:
Dein Einsatz in Ehren aber man wird wohl Betriebsblind mit der Zeit, es muss ja immer das gleiche sein alle keine Ahnung, ich habe zumindest nichts der gleichen behauptet oder hohe Erwartungen an die Genauigkeit.
Um es ganz einfach zu halten, vor dem Firmware Update Hoymiles etwa 600W, Shelly etwa 600w.
Nach dem Update Hoymiles etwa 600W Shelly etwa 710W. Habe das setup 3 mal im Einsatz, bei allen das gleiche nach dem mit dem Update.
Das versaut die Statistik, liegt komplett daneben und hat nichts mehr Abweichungen die sich im Rahmen halt immer ergeben zu tun. Gilt leider auch für die kWh. Ich erfasse die Werte alle 2s in einer InfluxDB, das Problem ist aber immer da nicht nur wenn die Sonneneinstrahlung schwankt.
Das gab es schonmal um die Version 0.11 rum, bis sie es nach viel viel viel hin und her gelöst haben. Danach war alles im Rahmen bis halt das Februar update es wieder versaut hat.
Auch mit der aktuellen 1.4.4 ist die Messung weiter etwa 18% daneben. Unfassbar das es bis auf 2-3 Leute hier niemanden inkl. Shelly interressiert 
Auch mit der 1.4 beta3 sind die Werte bei mir weiter 17-18% zu hoch. Falls jemand Facebook nutzt bitte mal dort posten.. Super QA das sie das seit Monaten nicht merken...
Unglaublich immer kommt so ein Kommentar, wie hilfreich WOW. Die Firmware wurde mal wieder verbuggt, das "update" bringt ~17% Abweichung. Aber wie jedes mal wenn sie eine Firmware Versauen kommen erstmal Fanboy Kommentare die den Fehler rechtfertigen. Schon auf Vorlage wenn etwas zur Messung kommt -> das ist kein Messgerät Mimimi, gar nicht erst damit auseinander setzen.
Jetzt heißt es ein paar Monate warten, bis sie es mal merken bzw. die Tickets dazu ernst nehmen.
Same issue here, MiniPV with a maximum of 600W is measured with 700W.
Could not belive that this is happening again after all the trouble the 0.11, 0.12 made, mess up my statistics several times and now again. They should be experts in regression testing for this Topic meanwhile.
Still happen on 1.3 as well.
Overall it seems still OK, it is some times dropping 3-4 Volts but it looks like the ECO Mode has an Impact on the Voltage reading. For me it is consitently to low when enabled.
Please refer to the Graph below. Red line is the real Volatage, consistenly measured from 3 different Inverters, of couse also changing depending on the Powergird but at the time taken almost stable.
Green: Eco Mode ON, Voltage is to low. sometimes even drops by 4-5 Volt.
Yellow: Reboot Shortly recovers but drops again after a few seconds
Blue: Eco Mode OFF, brings it pretty close to the real Value
Green: Eco Mode ON, Voltage drops again
Seems to be fixed with v0.13, the blue dots are stable while on the older Version green, yellow startet osscilation several times again.
@mircho.mirev
2nd the previous Post, the yellow line is on v0.13.0-beta1, the two other still on v0.10.2, behaviour seems even worse now. The spikes are even bigger and fluctuating with a higher freuquency, at least about every 2 seconds, refer to the second graph (might be even higher but not caputuring with high freq.). After restart around 23:42 it returned to normal.
Hi,
I tried to adapt the newly provided scripts to use the BLE functionality to receive Data from an Inkbird IBS-TH2 Temperature, Humidity Sensor to later publish it via MQTT. But it seems the received Data is incomplete, advertisment and scanrespsone is available but the Manufacturer Data which seems to hold the real information is empty.
Any Idea what I'm doing wrong or having any of the Inbird Sensors working?
KR
Running 0.12.0-beta2
Script:
let CONFIG = {
sensorName: "sps",
sensorAddress: "49:xx:xx:xx:xx:xx"
};
let IBSTH2_SERVICE_UUID = "FFF0";
function ParseIBSData(data, source)
{
//TBD
}
function bleResult(event, result)
{
if (event !== BLE.Scanner.SCAN_RESULT) return;
if (result === null) return;
let sensorName = BLE.GAP.ParseDataByEIRType(result.scanRsp, BLE.GAP.EIR_FULL_NAME);
let publicAdress = BLE.GAP.ParseDataByEIRType(result.scanRsp, BLE.GAP.ADDRESS_TYPE_PUBLIC);
//print("Sensor:" + sensorName + "Adress:" + result.addr + "publicAdress:" + publicAdress);
//print(result.local_name);
if (sensorName !== CONFIG.sensorName) return;
if (CONFIG.sensorAddress !== "" && result.addr !== CONFIG.sensorAddress) return;
print(result.local_name);
print(result.rssi);
let datas = BLE.GAP.ParseServiceData(result.advData, IBSTH2_SERVICE_UUID);
let data = BLE.GAP.ParseManufacturerData(result.advData);
let datam = BLE.GAP.ParseDataByEIRType(result.advData, BLE.GAP.EIR_MANUFACTURER_SPECIFIC_DATA);
print("Manfac data: " + data);
print("Manufac EIR data: " + datam);
print("advData: "result.advData);
print("scanRSP: "result.scanRsp);
print(result.manufacturer_data);
print(result.service_uuids);
print(result.service_data);
print(result.tx_power_level);
//for (let i=0; i < result.manufacturer_data.length; i++) {
//print(result.manufacturer_data[i]);
//}
let i;
for (let prop in result.manufacturer_data) {
print(prop, ' - ', typeof (result.manufacturer_data[i]));
}
}
// scan for ble devices
BLE.Scanner.Start({
duration_ms: -1,
active: true }, bleResult);Result:
sps
-50
Manfac data:
Manufac EIR data:
advData: \x02\x01\x06\x03\x02\xf0\xff
scanRSP: \x04\x09sps\x0a\xff\x0b\x05\xbe\x1b\x00\xeb\xd9d\x08
<object>
<array>
undefined
undefined
050b - undefinedHallo zusammen,
habe ich mich an den Bereitgestellen Skripten für BLE versucht um damit die Werte eines Inkbird IBS-TH2 zu empfangen und die Daten dann über MQTT weiter zu Verarbeiten. Leider komme ich nicht an die Werte. Der Sensor wird gefunden und es werden auch die Advertisements und Scanresponse empfangen aber die Manufacturer Daten wo wohl die Werte drin stecken sind leer.
Hat jemand den Sensor im Einsatz und kann es mal probieren, bzw. hat jemand eine Idee warum hier nichts kommt?
let CONFIG = {
sensorName: "sps",
sensorAddress: "49:xx:xx:xx:xx:xx"
};
let IBSTH2_SERVICE_UUID = "FFF0";
function ParseIBSData(data, source)
{
//TBD
}
function bleResult(event, result)
{
if (event !== BLE.Scanner.SCAN_RESULT) return;
if (result === null) return;
let sensorName = BLE.GAP.ParseDataByEIRType(result.scanRsp, BLE.GAP.EIR_FULL_NAME);
let publicAdress = BLE.GAP.ParseDataByEIRType(result.scanRsp, BLE.GAP.ADDRESS_TYPE_PUBLIC);
//print("Sensor:" + sensorName + "Adress:" + result.addr + "publicAdress:" + publicAdress);
//print(result.local_name);
if (sensorName !== CONFIG.sensorName) return;
if (CONFIG.sensorAddress !== "" && result.addr !== CONFIG.sensorAddress) return;
print(result.local_name);
print(result.rssi);
let datas = BLE.GAP.ParseServiceData(result.advData, IBSTH2_SERVICE_UUID);
let data = BLE.GAP.ParseManufacturerData(result.advData);
let datam = BLE.GAP.ParseDataByEIRType(result.advData, BLE.GAP.EIR_MANUFACTURER_SPECIFIC_DATA);
print("Manfac data: " + data);
print("Manufac EIR data: " + datam);
print("advData: "result.advData);
print("scanRSP: "result.scanRsp);
print(result.manufacturer_data);
print(result.service_uuids);
print(result.service_data);
print(result.tx_power_level);
//for (let i=0; i < result.manufacturer_data.length; i++) {
//print(result.manufacturer_data[i]);
//}
let i;
for (let prop in result.manufacturer_data) {
print(prop, ' - ', typeof (result.manufacturer_data[i]));
}
}
// scan for ble devices
BLE.Scanner.Start({
duration_ms: -1,
active: true }, bleResult);Ergebnis:
sps
-79
Manfac data:
Manufac EIR data:
advData: \x02\x01\x06\x03\x02\xf0\xff
scanRSP: \x04\x09sps\x0a\xff\x15\x04\x13$\x00\xc26d\x08
<object>
<array>
undefined
undefined
0415 - undefinedGreets
Nein, 12 Stellig
Edit: Habe ihn vor etwa 1,5 Jahren eingebunden seit dem lag er rum. Sollte die ID mit Firmwareupdate auf die letzte Version automatisch umgestellt worden sein könnte es damit zusammenhängen.
GW&DNS sind hinterlegt. Habe ihn gelöscht, danach wurde er unter discovered devices angezeigt, konnte aber nicht hinzugefügt werden. Über die IP ging es auch nicht, ungültiges Gerät oder so ähnlich.
Dann über den Shelly selbst Cloud deaktiviert, danach wurde er entdeckt und ohne weitere Nachfrage mit der Cloud verbundenen, seit dem scheint es zu laufen.
Issue resolved