@derdom
Servus, das klingt gut 
Nur zur Info, falls du es noch nicht kennst, so eine konstante Abweichung kannst du, wenn gewünscht, in den Einstellungen des BM kompensieren - bei mir im BM1 ist es der Parameter A15, den ich von -5 bis +5 Grad einstellen kann.
Sieh’ dir dazu nur auch die Montageanleitung zu deinem BM an, da sollte es genau beschrieben sein.
@lxffm
Ich habe eine inventwo Multi Widget für meinen Rolladen in Kombination mit Fenster/Terassentür offen mit insgesamt 4 Zustände im Einsatz. Dazu habe ich mir aber mit Javascript einen Datenpunkt Rolladen in Bewegung gebaut.
Im Widget frage ich
im Zustand [0] 100 als Rolladen geschlossen,
im Zustand [1] true als in Bewegung,
im Zustand [2] true als Fenster/Terrassentür geöffnet und
im Zustand [3] 0 als Rolladen geöffnet ab
und zeige mir dazu jeweils ein entsprechendes Symbol an. Das funktioniert für mich so, wie es soll.
Ich denke in deinem Fall musst du
im Zustand [0] die greaterequal 95, dann
im Zustand [1] die lower 5 und
im Zustand [2] dann die lower 95
abfragen.
Ich probiere hier auch immer wieder herum, denke aber, dass der erste „wahre“ Zustand greift.
im Skript das @2 weglassen (das ist nur für den Installer, dass er die v2 installiert und nicht die v3), d.h.
const fetch2 = require('node-fetch');
@lucky_esa sagte in Test Adapter LG ThinQ v0.0.1:
Kannst du bitte noch mal testen.
Hallo Lucky,
Installation war jetzt problemlos und die thinq2 Geräte funktionieren wie gewohnt.
Und das thinq1 Gerät lässt sich einwandfrei, sowie wie von dir beschrieben einschalten und auch im snapshot wird der DP Operation sauber aktualisiert.
Zurück Ausschalten - mit xxx.remote.settings.Operation = AUS(0) und danach xxx.remote.SetOperation = true hat leider nicht funktioniert. (habe dann auch probiert auf false und dann wieder auf true - leider auch ohne Ergebnis)
Nach dem Ausschalten über die Fernbedienung hat dann erneutes Einschalten mit xxx.remote.settings.Operation = Rechts an(1) und danach xxx.remote.SetOperation = true wieder einwandfrei funktioniert.
Zurück Ausschalten leider wieder nicht, es kommt aber auch da irgendwas bei der Klima an, denn sie gibt ein Signal von sich wenn ich xxx.remote.SetOperation = true setze, aber sie schaltet nicht aus. Der snapshot wird nach dem Ausschalten mit der Fernbedienung leicht zeitverzögert entsprechend auf AUS(0) aktualisiert.
Habe dann auch noch direkt xxx.snapshot.Operation = AUS(0) versucht, da kommt dann im Log:
lg-thinq.0 2023-06-25 13:59:43.566 error AxiosError: Request failed with status code 400
lg-thinq.0 2023-06-25 13:59:43.566 error Send failed
Wie auch von @Merlin123 beschrieben ist bei mir auch in der App das Gerät mit "Wohnzimmer ist in Verwendung. Versuchen Sie es später noch einmal." gesperrt.
Ich habe das in vis in einem basic-html Widget für einen View-Wechsel so gelöst:
<table width=100% height=100% style="border-collapse:collapse; cursor: pointer;" onclick="changeView(10)">
...
Im Reiter Skripte ist dann folgendes js enthalten:
//Wechseln der View bei Click --- Aufrufbsp: changeView(8)
function changeView(view = 0) {
servConn.setState('linkeddevices.0.VIS.LINK', view);
}
@pingo sagte in setState String erzeugt Fehlermeldung:
setState('vw-connect.0.WV2ZZZEB4RH004449.status.chargingSettings.maxChargeCurrentAC'/maxChargeCurrentAC/,reduced);
Ich würde tippen, dass reduced jetzt keine Variable ist, oder?
Dann musst du das in Anführungszeichen setzen.
setState('vw-connect.0.WV2ZZZEB4RH004449.status.chargingSettings.maxChargeCurrentAC'/*maxChargeCurrentAC*/,"reduced");
@chris76e sagte in Ecovacs Deebot Adapter: Status und Feedback:
Einfach auf change beim ...status.device ist ja auch nicht richtig, bevor charging kommt, kommt ja noch returing.....
Ja klar, da müsstest du dann auch in dem "on.." die Auswertung der .ts und auch den Status getState('ecovacs-deebot.0.status.device').val == 'charging' mit einbauen.
Kann dir leider, wie gesagt, aktuell kein Codebeispiel im Detail zusammenstellen, da ich es nicht testen könnte.
Aber als Idee so ungefähr in der Richtung dann z.B.:
on({id: ['ecovacs-deebot.0.status.device', 'ecovacs-deebot.0.cleaninglog.lastCleaningTimestamp'] , change: "gt"}, function(obj){
if (getState('ecovacs-deebot.0.status.device').val == 'cleaning' && getState('ecovacs-deebot.0.status.device').ts < getSate('ecovacs-deebot.0.cleaninglog.lastCleaningTimestamp').ts) {
};
});
Ev. brauchst dann noch eine zusätzliche Prüfung, wenn die Aktualisierung von "lastCleaningTimestamp" doch schon vor der Statusänderung zu "cleaning" erfolgt.
Wollte dir damit nur ein paar Gedankenanregungen lieferen.
@homoran
Letztes OT:
Eigentlich schräg, aber hin und wieder hat der Apfel so seine Eigenheiten … dann war‘s in dem Fall ja doch ein Problem hinter und nicht vor der Tastatur 
Hallo in die Runde,
ich bin recht neu hier und beschäftige mich erst seit Jahreswechsel mit dem ioBroker und seinen Möglichkeiten.
Der Ecovacs Deebot Adapter ist einer meiner ersten Projekte in der Vis und ich finde den echt genial, großes Dankschön dafür an @mrbungle64.
Eine Punkt ist mir aufgefallen, mein T9 hat die Lufterfrischerkapseln eingebaut, hier finde ich jedoch leider keinen Datenpunkt dazu in den consumables, besteht da irgendeine Möglichkeit auch an diesen zu kommen? Die Suche hat mir dazu leider auch nicht weitergeholfen.
Vom Adapter habe ich gerade die v1.4.13-alpha.11 installiert.
Falls es jemanden interessiert, so sieht die Vis aktuell aus; ein paar Ideen dazu habe ich noch, vor Allem im Bereich der Karte.
Servus,
ich hatte auch immer wieder mal eigenartige Effekte in der Richtung (nutze auch mehrere Javascript-Instanzen).
Daher baue ich es mir in all meinen Skripten so auf (Besipielauszug aus einem Skript von mir):
let electricConsumtionTimer = schedule({hour: 23, minute: 59, second: 59}, setMeterReadings)
onStop(() => {
clearSchedule(electricConsumtionTimer);
electricConsumtionTimer = null;
}, 1000)
Das "electricConsumtionTimer = null" im onStop ist nicht unbedingt erforderlich, ist eher der Hosenträger zum Gürtel;
Das funktioniert bei mir einwandfrei und seitdem habe ich keine parallel laufenden Schedules mehr erkennen können.
Im selben Prinzip mache ich das auch mit setInterval und setTimeout.
onStop siehe ioBroker.javascript Doku
würde ich so lösen:
const l_tibberlink = "tibberlink.0.Homes.cf930f37-ceea-4c0c-a941-b395fb865fc3.PricesToday.";
const l_pvforecast = "pvforecast.0.summary.energy.hoursToday.";
const l_Strompreise = "0_userdata.0.Strompreise";
let arr = {};
for (let i = 0; i < 24; i++) {
arr[i] = {
level: getState(l_tibberlink + i + ".level").val,
price: getState(l_tibberlink + i + ".total").val,
pvSolcast: (i < 5 || i > 21) ? 0 : getState(l_pvforecast + (i < 10 ? ("0" + i) : i) + ":00:00").val
};
}
setState(l_Strompreise, JSON.stringify(arr), true);
log(JSON.parse(getState(l_Strompreise).val)[18]); //z.b. für Stunde 18
@kBrausew
Das findest du beim jew. Adapter im channel „info“, state „connection.
z.B. hmip.0.info.connection
@tombox
Ok, herzlichen Dank für deine Bemühungen, ich werde die mal anschreiben.
@tombox
Ja, das ist richtig, aber eben keine Statusdatenpunkte, sondern nur die Datenpunkte für das aktive Programm.
Ich kann mir nur schwer Vorstellen, dass es an home connect liegt, denn z.B. der Türstatus wird in der App am iPad immer korrekt angezeigt. Auch dann wenn im Adapter die Datenpunkte in status nicht aktualisiert worden sind.
@tombox
Ich hoffe ich verstehe dich jetzt nicht falsch, aber das log, dass ich in meinem obigen Post eingestellt habe, ist genau eines wo nichts passiert; d.h. die Datenpunkte in status (z.B. homeconnect.0.SIEMENS-WM14VG43-68A40E96CD6F.status.BSH_Common_Status_DoorState) werden nicht aktualisiert.
Hier ist jetzt z.B. für den Türstatus ein Log wo es funktioniert, sprich ich schalte die WM ein,
2024-04-14 16:52:10.821 - debug: homeconnect.0 (1570) event: {"type":"CONNECTED","data":"{\"haId\":\"SIEMENS-WM14VG43-68A40E96CD6F\",\"handling\":\"none\",\"key\":\"BSH.Common.Appliance.Connected\",\"level\":\"hint\",\"timestamp\":1713106330,\"value\":true}","lastEventId":"SIEMENS-WM14VG43-68A40E96CD6F","origin":"https://api.home-connect.com"}
2024-04-14 16:52:10.822 - info: homeconnect.0 (1570) CONNECTED: SIEMENS-WM14VG43-68A40E96CD6F
2024-04-14 16:52:12.471 - debug: homeconnect.0 (1570) event: {"type":"STATUS","data":"{\"haId\":\"SIEMENS-WM14VG43-68A40E96CD6F\",\"items\":[{\"handling\":\"none\",\"key\":\"BSH.Common.Status.DoorState\",\"level\":\"hint\",\"timestamp\":1713106332,\"uri\":\"/api/homeappliances/SIEMENS-WM14VG43-68A40E96CD6F/status/BSH.Common.Status.DoorState\",\"value\":\"BSH.Common.EnumType.DoorState.Closed\"}]}","lastEventId":"SIEMENS-WM14VG43-68A40E96CD6F","origin":"https://api.home-connect.com"}
2024-04-14 16:52:12.472 - debug: homeconnect.0 (1570) SIEMENS-WM14VG43-68A40E96CD6F.status.BSH_Common_Status_DoorState:BSH.Common.EnumType.DoorState.Closed
2024-04-14 16:52:12.476 - debug: homeconnect.0 (1570) Set event state
2024-04-14 16:52:12.487 - debug: homeconnect.0 (1570) Extend common option: homeconnect.0.SIEMENS-WM14VG43-68A40E96CD6F.status.BSH_Common_Status_DoorState
So wie es für mich aussieht kommt connected immer korrekt, aber danach werden die Statusdatenpunkte nicht immer abgerufen.
Hier ein debug-Log vom Einschalten der WM, wo die Datenpunkte unter status nicht aktualisiert werden. Soweit ich das sehe, kommt das connected gut an.
Habe jetzt noch kein Log von einem Einschalten, wo die Datenpunkte unter status auch aktualisiert werden, aber ev. hilft das schon mal weiter.
2024-04-14 12:23:57.115 - debug: homeconnect.0 (1957879) event: {"type":"CONNECTED","data":"{\"haId\":\"SIEMENS-WM14VG43-68A40E96CD6F\",\"handling\":\"none\",\"key\":\"BSH.Common.Appliance.Connected\",\"level\":\"hint\",\"timestamp\":1713090237,\"value\":true}","lastEventId":"SIEMENS-WM14VG43-68A40E96CD6F","origin":"https://api.home-connect.com"}
2024-04-14 12:23:57.127 - info: homeconnect.0 (1957879) CONNECTED: SIEMENS-WM14VG43-68A40E96CD6F
Vollständig siehe homeconnect_log_2024-04-14.txt
@tombox
Danke für deine Rückmeldung. Mache ich und melde mich mit dem Ergebnis dann in einigen Tagen.
Hallo in die Runde, @tombox
ich nutze den Adapter in Verbindung mit einer Siemens Waschmaschine. An sich funktioniert alles problemlos.
Die WM hat aber die Eigenschaft, dass sie bei Abschalten auch die WLAN-Verbindung abschaltet. Adapter reagiert da korrekt mit connection = false.
Beim Wiedereinschalten nach einigen Tagen wird auch connection wieder true, aber die status Datenpunkte, wie z.B. homeconnect.0.SIEMENS-WM14VG43-68A40E96CD6F.status.BSH_Common_Status_DoorState werden nicht mehr aktualisiert. Dies aber erst, wenn die WM wirklich ein paar Tage abgeschalten ist. Wenn sie nur ein paar Stunden aus ist und dann wieder eingeschalten wird, tritt das Verhalten nicht auf.
Nach Neustart des Adapters funktioniert alles wieder problemlos.
Datenpunkte nach Einschalten nach ein paar Tagen WM aus:
Datenpunkte nach Adapter Neustart:
ioBroker läuft auf einen Raspi 4 8GB mit dzt. noch bullseye und Node v18.19.1,
js-controller 5.0.19 und Adapterversion v1.3.0
