@fichte Sehr seltsamer Effekt!
Ich lese auch mit Tasmota meinen Zweirichtungszähler aus. Welche Werte liefert denn deiner?
Bei meinem bekomme ich Gesamtverbrauch (kWh), Gesamteinspeisung (kWh) und aktueller Verbrauch/Einspeisung (W).
Meine Einstellung sind an sich identisch mit deinen für die beiden Datenpunkte Gesamt-Verbrauch und Gesamt-Einspeisung außer, dass ich als Einheit für total_in und total_out kWh gewählt habe.
Lässt du SA auf den Datenpunkt mit dem aktuellen Wert rechnen oder warum in W?

@manfredhi sagte in [SourceAnalytix 0.4.8-Final] Released !:

uncaught exception: ENOENT: no such file or directory, open '/opt/iobroker/log/iobroker.

Schau mal hier, vor allem der letzte Eintrag. Vielleicht hilft das weiter. Ich hatte den Fall selbst noch nie.
https://forum.iobroker.net/topic/68247/gelöst-source-analytix-fehlerhaft?_=1697624793036

@manfredhi sagte in [SourceAnalytix 0.4.8-Final] Released !:

@derelvis sagte in [SourceAnalytix 0.4.8-Final] Released !:

Vielleicht mag es ja mal jemand testen (auf eigene Gefahr) und Rückmeldung geben?

Hab das in der main.js eingetragen. Hat bei der SA Instanz 1 einwandfrei funktioniert. Bei der Instanz 0 nicht, weil plötzlich kein Logfile vom 17.10. da war (siehe meinen Eintrag darüber). Warum das logfile weg war und die SA-Instanz gestoppt hat weiß ich nicht, mit den Einträgen von dir dürfte es nicht zusammenhängen, da es bei der Instanz 1 ja funktioniert hat.

Cool, freut mich

@nieip @m4rgott

Das Problem des fehlenden Übertrags der meterReadings in "prevDay, prevWeek, prevMonth, prevYear" kann man wie folgt beheben:

• folgenden Kommentar in der iobroker/node_modules/iobroker.sourceanalytix/main.js suchen (ca. Zeile 852) und darunter

							//ToDo: Think / discuss what to do with meter readings
							// Handle meter reading states
							// if (this.config.currentYearPrevious) await this.setStateAsync(`${stateID}.currentYear.meterReadings.previousWeek.${weekdays[x]}`, {
							// 	val: await this.getStateAsync(`${stateID}.currentYear.meterReadings.currentWeek.${weekdays[x]}`),
							// 	ack: true
							// })

• folgenden Block einfügen:

							//derelvis: copy cumulativeReading into prevValue 
							if (beforeReset.day !== actualDate.day) {
								await this.setPreviousValues(`${stateDetails.deviceName}.cumulativeReading`, `${stateDetails.deviceName}.currentYear.meterReadings.01_previousDay`);
							}

							if (beforeReset.week !== actualDate.week) {
								await this.setPreviousValues(`${stateDetails.deviceName}.cumulativeReading`, `${stateDetails.deviceName}.currentYear.meterReadings.02_previousWeek`);
							}

							if (beforeReset.month !== actualDate.month) {
								await this.setPreviousValues(`${stateDetails.deviceName}.cumulativeReading`, `${stateDetails.deviceName}.currentYear.meterReadings.03_previousMonth`);
							}

							if (beforeReset.quarter !== actualDate.quarter) {
								await this.setPreviousValues(`${stateDetails.deviceName}.cumulativeReading`, `${stateDetails.deviceName}.currentYear.meterReadings.04_previousQuarter`);
							}

							if (beforeReset.year !== actualDate.year) {
								await this.setPreviousValues(`${stateDetails.deviceName}.cumulativeReading`, `${stateDetails.deviceName}.currentYear.meterReadings.05_previousYear`);
							}
							//derelvis end

• danach (ca. Zeile 888) sollte es so weitergehen:

						}

						await this.extendForeignObject(stateID, obj);
						this.log.info(`Memory values after reset : ${JSON.stringify(this.activeStates[stateID])}`);

• Instanz SourceAnalytics neustarten

So werden dann auch die MeterReadings aus dem Datenpunkt cumulativeReading (fortlaufender Zählerstand) zu den jeweiligen Zeitpunkten in die prevValues übernommen, wie bei den anderen Kategorien. Läuft bei mir so seit letztem Sonntag:

Wenn man sich 01_previousDay per Signal/Telegramm usw. bei Änderung schicken lässt, sollte man um Mitternacht das erste mal einen Zählerstand bekommen. Praktisch kann man sich so dann auch per history oder influx die jeweils monatlichen oder jährlichen Zählerständer loggen.

Vielleicht mag es ja mal jemand testen (auf eigene Gefahr) und Rückmeldung geben?

@tbsjah Sehr geil!!!
So weit war ich auch schon fast gekommen.

Aber ich komm mit dem Object/Json noch nicht klar:
https://github.com/UncleSamSwiss/ioBroker.luxtronik2/issues/184#issuecomment-1326132449

Mit Java meinte ich das alte Java Interface das die Firmware V2.79 noch bereitstellt. Läuft bei mir noch in einer VirtualBox Win10 VM mit Firefox 52.9.0 ESR und Java 8 Update 261 (alle Updates blockiert sonst funktioniert nichts mehr, zusätzlich Snapshot).
Zugriff geht per http://ip

Damit kann so ziemlich alles konfiguriert werden was die Steuerung hergibt, so man denn die entsprechenden Passwörter hat. Deshlab wollt ich nie auf eine neuere FW wechseln in der Angst, dass mit dem neuen Webinterface-Interface kaum mehr was zu machen ist (Changelogs sind ja nicht wirklich zu finden).
Und nachdem meine Novelan-App nicht mal per VPN an die Lux kommt (mangels Möglichkeit der IP Eingabe - stattdessen Broadcast), wäre das echt übel.

TbsJah created this issue in UncleSamSwiss/ioBroker.luxtronik2

open Timer table configurations #184

@jb-m Servus,
wenn ich es richtig sehe und verstehe ist das leider nur ein Return Value und nicht schreibbar wie die Parameter. Ob man das so einfach ändern kann oder es aufgrund der API oder des Board Designs nicht möglich ist, bin ich mir nicht sicher.
Wenn man die von mir oben angefragten Timer Tabellen integriert, könnte man die Zirkulation aber quasi per Zeitumstellung von hotWaterCircPumpTimerTable hintricksen. Nicht schön aber könnte klappen als Workaround (Zeitplan in iob ändern oder der Taster setzt den Zeitplan auf now + 10 min. z.B.).

@unclesam
Mega geile Arbeit!! Der Adapter ist echt klasse Vielen Dank dafür!
Wie hoch stehen die Chancen die Datenpunkte für die Timer Tabellen (Heizen, WW & Zirkulation) aus der Library umzusetzen? Mangels alter Java Version und Firefox komme ich nur noch per VM an diese Einstellungen. Da wäre die Verfügbarkeit in ioBroker der totale Hammer.

@Rene_HM Sehr geil! Vielen Dank

Servus,
habe das gleiche Problem.
Wert aus der verwendeten XML Datei:

Wert in ioBroker:

Scheint mir eher ein Rundungsproblem oder eine falsche Formatierung des Wertes im DasWetter Adapter zu sein.
Die Werte kommen schon als englische Kommazahlen von DasWetter wie die XML zeigt: 0.2 mm
Habe aber keine Stelle gefunden an der man da was justieren könnte.

Ebenfalls DasWetter 3.0.3

Danke für jeden Tipp

Grüße Daniel

Ok, eben entdeckt. Es gibt auf github bereits ein issue dazu:
https://github.com/rg-engineering/ioBroker.daswetter/issues/76

Elvissimo created this issue in rg-engineering/ioBroker.daswetter

closed better rain values #76