Test Adapter melcloud v2.0.x Latest

[galdreth]

Hi, mit der neuen Version beobachte ich bei mir sehr reproduzierbar Verbindungsausfälle und das unabhängig von den Intervallen (3, 5, 15, 60) ausprobiert.

Jeden Tag ist das letzte Aktualisierungsintervall entweder genau vor 7:00 oder vor 17:00, wenn ich in der Melcloud App nachschaue. Der Adapter in Iobroker bekommt ab da keine Daten mehr, auch wenn ich ihn neustarte.

Das Problem verschwindet erst nach Neustart des WiFi-Adapters an der Wärmepumpe (Mitsubishi Geodan). Ich habe jetzt auch schon 3 verschiedene WiFi-Netze ausprobiert und davon 2 an verschiedenen Routern.

Hat jemand ähnliches beobachtet?

Hier der Debug-Output von heute morgen.

2024-02-27 07:39:29.376 - info: host.smarthome stopInstance system.adapter.melcloud.0 (force=false, process=true)
2024-02-27 07:39:29.378 - info: host.smarthome stopInstance system.adapter.melcloud.0 send kill signal
2024-02-27 07:39:29.378 - info: melcloud.0 (8238) Got terminate signal TERMINATE_YOURSELF
2024-02-27 07:39:29.378 - debug: melcloud.0 (8238) Cleared polling timer.
2024-02-27 07:39:29.378 - debug: melcloud.0 (8238) Cleared context key invalidation timer.
2024-02-27 07:39:29.379 - info: melcloud.0 (8238) onUnload(): Cleaned everything up...
2024-02-27 07:39:29.379 - info: melcloud.0 (8238) terminating
2024-02-27 07:39:29.379 - info: melcloud.0 (8238) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2024-02-27 07:39:29.902 - info: host.smarthome instance system.adapter.melcloud.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2024-02-27 07:39:32.403 - info: host.smarthome instance system.adapter.melcloud.0 started with pid 8253
2024-02-27 07:39:32.706 - debug: melcloud.0 (8253) Redis Objects: Use Redis connection: 127.0.0.1:9001
2024-02-27 07:39:32.732 - debug: melcloud.0 (8253) Objects client ready ... initialize now
2024-02-27 07:39:32.733 - debug: melcloud.0 (8253) Objects create System PubSub Client
2024-02-27 07:39:32.733 - debug: melcloud.0 (8253) Objects create User PubSub Client
2024-02-27 07:39:32.766 - debug: melcloud.0 (8253) Objects client initialize lua scripts
2024-02-27 07:39:32.769 - debug: melcloud.0 (8253) Objects connected to redis: 127.0.0.1:9001
2024-02-27 07:39:32.782 - debug: melcloud.0 (8253) Redis States: Use Redis connection: 127.0.0.1:9000
2024-02-27 07:39:32.789 - debug: melcloud.0 (8253) States create System PubSub Client
2024-02-27 07:39:32.789 - debug: melcloud.0 (8253) States create User PubSub Client
2024-02-27 07:39:32.801 - debug: melcloud.0 (8253) States connected to redis: 127.0.0.1:9000
2024-02-27 07:39:32.864 - info: melcloud.0 (8253) starting. Version 1.3.7 in /opt/iobroker/node_modules/iobroker.melcloud, node: v19.9.0, js-controller: 4.0.21
2024-02-27 07:39:32.875 - debug: melcloud.0 (8253) Initializing objects...
2024-02-27 07:39:32.929 - debug: melcloud.0 (8253) Checking adapter settings...
2024-02-27 07:39:32.930 - debug: melcloud.0 (8253) Getting current known devices...
2024-02-27 07:39:32.959 - debug: melcloud.0 (8253) Found known device: 42490188
2024-02-27 07:39:32.959 - info: melcloud.0 (8253) Connecting initially to MELCloud and retrieving data...
2024-02-27 07:39:32.960 - debug: melcloud.0 (8253) Fetching context key...
2024-02-27 07:39:33.244 - debug: melcloud.0 (8253) Received response from: https://app.melcloud.com/Mitsubishi.Wifi.Client/Login/ClientLogin (status code: 200 - OK)
2024-02-27 07:39:33.245 - debug: melcloud.0 (8253) Response from cloud: {"ErrorId":null,"ErrorMessage":null,"LoginStatus":0,"UserId":0,"RandomKey":null,"AppVersionAnnouncement":null,"LoginData":{"ContextKey":"0-A7898A86A4124A8D967CC3B86C26DC-528497-1","Client":528497,"Terms":1282,"AL":1,"ML":0,"CMI":true,"IsStaff":false,"CUTF":false,"CAA":false,"ReceiveCountryNotifications":false,"ReceiveAllNotifications":false,"CACA":false,"CAGA":false,"MaximumDevices":10,"ShowDiagnostics":false,"Language":4,"Country":85,"RealClient":0,"Name":"Michael Ramolla","UseFahrenheit":false,"Duration":525600,"Expiry":"2025-02-26T07:39:33.18","CMSC":false,"PartnerApplicationVersion":null,"EmailSettingsReminderShown":true,"EmailUnitErrors":0,"EmailCommsErrors":0,"ChartSeriesHidden":262272,"DeletePending":false,"Throttle":true,"IsImpersonated":false,"LanguageCode":"de","CountryName":"Deutschland","CurrencySymbol":"€","SupportEmailAddress":null,"DateSeperator":"/","TimeSeperator":":","AtwLogoFile":"ecodan_logo.png","DECCReport":false,"CSVReport1min":false,"HidePresetPanel":false,"EmailSettingsReminderRequired":false,"TermsText":null,"MapView":false,"MapZoom":19,"MapLongitude":10.103961653225156,"MapLatitude":48.788148579801835,"Throttled":false},"ListPendingInvite":[],"ListOwnershipChangeRequest":[],"ListPendingAnnouncement":[],"LoginMinutes":0,"LoginAttempts":0,"EnableRegistration":true,"EnableEditStructure":true,"EnableFrostProtection":true,"EnableHolidayMode":true,"EnableTimer":true,"EnableScenes":true,"EnableInviteNewGuests":true,"EnableManageGuestAccess":true,"EnableControlOfGuestDevices":true}
2024-02-27 07:39:33.245 - debug: melcloud.0 (8253) Login successful. ContextKey: 0-A7898A86A4124A8D967CC3B86C26DC-528497-1
2024-02-27 07:39:33.245 - debug: melcloud.0 (8253) Fetching devices...
2024-02-27 07:39:33.339 - debug: melcloud.0 (8253) Received response from: https://app.melcloud.com/Mitsubishi.Wifi.Client/User/ListDevices (status code: 200 - OK)
2024-02-27 07:39:33.340 - debug: melcloud.0 (8253) Response from cloud: [{"ID":404862,"Name":"xxxx","AddressLine1":"Musterweg 15","AddressLine2":null,"City":"Musterstadt","Postcode":"12345","Latitude":38.788077,"Longitude":14.1039255,"District":null,"FPDefined":true,"FPEnabled":false,"FPMinTemperature":10,"FPMaxTemperature":12,"HMDefined":true,"HMEnabled":false,"HMStartDate":null,"HMEndDate":null,"BuildingType":1,"PropertyType":8,"DateBuilt":null,"HasGasSupply":true,"LocationLookupDate":"2022-06-03T06:50:26.447","Country":85,"TimeZoneContinent":3,"TimeZoneCity":49,"TimeZone":119,"Location":119945,"CoolingDisabled":false,"LinkToMELCloudHome":false,"Expanded":true,"Structure":{"Floors":[],"Areas":[],"Devices":[{"DeviceID":42490188,"DeviceName":"MitsubishiGeodanWP","BuildingID":404862,"BuildingName":null,"FloorID":null,"FloorName":null,"AreaID":null,"AreaName":null,"ImageID":-1,"InstallationDate":null,"LastServiceDate":null,"Presets":[],"OwnerID":528497,"OwnerName":null,"OwnerEmail":null,"AccessLevel":4,"DirectAccess":false,"EndDate":"2500-01-01T00:00:00","Zone1Name":null,"Zone2Name":null,"MinTemperature":0,"MaxTemperature":40,"HideVaneControls":false,"HideDryModeControl":false,"HideRoomTemperature":false,"HideSupplyTemperature":false,"HideOutdoorTemperature":false,"EstimateAtaEnergyProductionOptIn":false,"EstimateAtaEnergyProduction":false,"BuildingCountry":null,"OwnerCountry":null,"AdaptorType":-1,"LinkedDevice":null,"Type":1,"MacAddress":"74:7a:90:c5:69:cd","SerialNumber":"2102128023","Device":{"PCycleActual":0,"ErrorMessages":"","DeviceType":1,"FTCVersion":1100,"FTCRevision":"r0","LastFTCVersion":0,"LastFTCRevision":null,"FTCModel":3,"RefridgerentAddress":0,"DipSwitch1":54,"DipSwitch2":160,"DipSwitch3":68,"DipSwitch4":0,"DipSwitch5":38,"DipSwitch6":16,"HasThermostatZone1":true,"HasThermostatZone2":true,"TemperatureIncrement":0.5,"DefrostMode":0,"HeatPumpFrequency":0,"MaxSetTemperature":35,"MinSetTemperature":20,"RoomTemperatureZone1":21,"RoomTemperatureZone2":-39,"OutdoorTemperature":6,"FlowTemperature":21,"FlowTemperatureZone1":16.5,"FlowTemperatureZone2":25,"FlowTemperatureBoiler":25,"ReturnTemperature":15,"ReturnTemperatureZone1":16.5,"ReturnTemperatureZone2":25,"ReturnTemperatureBoiler":25,"BoilerStatus":false,"BoosterHeater1Status":false,"BoosterHeater2Status":false,"BoosterHeater2PlusStatus":false,"ImmersionHeaterStatus":false,"WaterPump1Status":false,"WaterPump2Status":false,"WaterPump3Status":false,"ValveStatus3Way":false,"ValveStatus2Way":false,"WaterPump4Status":false,"ValveStatus2Way2a":false,"ValveStatus2Way2b":false,"TankWaterTemperature":13,"UnitStatus":0,"HeatingFunctionEnabled":true,"ServerTimerEnabled":false,"ThermostatStatusZone1":false,"ThermostatStatusZone2":false,"ThermostatTypeZone1":0,"ThermostatTypeZone2":2,"MixingTankWaterTemperature":25,"CondensingTemperature":40.57,"DemandPercentage":100,"ConfiguredDemandPercentage":null,"HasDemandSideControl":false,"DailyHeatingEnergyConsumed":5.42,"DailyCoolingEnergyConsumed":0,"DailyHotWaterEnergyConsumed":1.25,"DailyHeatingEnergyProduced":25.57,"DailyCoolingEnergyProduced":0,"DailyHotWaterEnergyProduced":4.25,"DailyLegionellaActivationCounter":0,"LastLegionellaActivationTime":"0001-01-01T00:00:00","EffectiveFlags":1,"LastEffectiveFlags":0,"Power":true,"EcoHotWater":true,"OperationMode":0,"OperationModeZone1":2,"OperationModeZone2":2,"SetTemperatureZone1":20,"SetTemperatureZone2":20,"SetTankWaterTemperature":45,"TargetHCTemperatureZone1":27,"TargetHCTemperatureZone2":35,"ForcedHotWaterMode":false,"HolidayMode":false,"ProhibitHotWater":true,"ProhibitHeatingZone1":false,"ProhibitHeatingZone2":false,"ProhibitCoolingZone1":false,"ProhibitCoolingZone2":false,"ServerTimerDesired":false,"SecondaryZoneHeatCurve":false,"SetHeatFlowTemperatureZone1":30,"SetHeatFlowTemperatureZone2":20,"SetCoolFlowTemperatureZone1":20,"SetCoolFlowTemperatureZone2":20,"DECCReport":false,"CSVReport1min":false,"Zone2Master":false,"DailyEnergyConsumedDate":"2024-02-26T00:00:00","DailyEnergyProducedDate":"2024-02-26T00:00:00","CurrentEnergyConsumed":0,"CurrentEnergyProduced":0,"CurrentEnergyMode":null,"HeatingEnergyConsumedRate1":0,"HeatingEnergyConsumedRate2":0,"CoolingEnergyConsumedRate1":0,"CoolingEnergyConsumedRate2":0,"HotWaterEnergyConsumedRate1":0,"HotWaterEnergyConsumedRate2":0,"HeatingEnergyProducedRate1":0,"HeatingEnergyProducedRate2":0,"CoolingEnergyProducedRate1":0,"CoolingEnergyProducedRate2":0,"HotWaterEnergyProducedRate1":0,"HotWaterEnergyProducedRate2":0,"ErrorCode2Digit":0,"SpSubDivisionsToWrite":0,"SpSubDivisionsToRead":0,"SpState":0,"SpSubDivisionsWriteInProgress":0,"SpSubDivisionsReadInProgress":0,"InitialSettingsData":null,"InitialSettingsTimestamp":null,"SupportsHourlyEnergyReport":false,"HasZone2":false,"HasSimplifiedZone2":false,"CanHeat":true,"CanCool":false,"HasHotWaterTank":true,"CanSetTankTemperature":true,"CanSetEcoHotWater":true,"HasEnergyConsumedMeter":true,"HasEnergyProducedMeter":true,"CanMeasureEnergyProduced":false,"CanMeasureEnergyConsumed":false,"Zone1InRoomMode":false,"Zone2InRoomMode":false,"Zone1InHeatMode":true,"Zone2InHeatMode":true,"Zone1InCoolMode":false,"Zone2InCoolMode":false,"AllowDualRoomTemperature":false,"IsGeodan":true,"HasEcoCuteSettings":false,"HasFTC45Settings":true,"HasFTC6Settings":true,"CanEstimateEnergyUsage":true,"CanUseRoomTemperatureCooling":false,"IsFtcModelSupported":true,"MaxTankTemperature":60,"IdleZone1":true,"IdleZone2":true,"MinPcycle":1,"MaxPcycle":1,"MaxOutdoorUnits":255,"MaxIndoorUnits":255,"MaxTemperatureControlUnits":0,"ModelCode":"027a","DeviceID":42490188,"MacAddress":"74:7a:90:c5:69:cd","SerialNumber":"2102128023","TimeZoneID":119,"DiagnosticMode":0,"DiagnosticEndDate":null,"ExpectedCommand":1,"Owner":528497,"DetectedCountry":null,"AdaptorType":-1,"FirmwareDeployment":null,"FirmwareUpdateAborted":false,"LinkedDevice":null,"WifiSignalStrength":-72,"WifiAdapterStatus":"NORMAL","Position":"Unknown","PCycle":1,"PCycleConfigured":null,"RecordNumMax":1,"LastTimeStamp":"2024-02-27T06:59:00","ErrorCode":8000,"HasError":false,"LastReset":"2022-06-03T07:43:27.78","FlashWrites":7,"Scene":null,"TemperatureIncrementOverride":0,"SSLExpirationDate":"2037-12-31T00:00:00","SPTimeout":1,"Passcode":null,"ServerCommunicationDisabled":false,"ConsecutiveUploadErrors":0,"DoNotRespondAfter":null,"OwnerRoleAccessLevel":1,"OwnerCountry":85,"HideEnergyReport":false,"ExceptionHash":null,"ExceptionDate":null,"ExceptionCount":null,"Rate1StartTime":null,"Rate2StartTime":null,"ProtocolVersion":0,"UnitVersion":0,"FirmwareAppVersion":19000,"FirmwareWebVersion":0,"FirmwareWlanVersion":0,"LinkToMELCloudHome":false,"LinkedByUserFromMELCloudHome":"00000000-0000-0000-0000-000000000000","EffectivePCycle":1,"MqttFlags":257,"HasErrorMessages":false,"Offline":true,"Units":[{"ID":1,"Device":0,"SerialNumber":"079229","ModelNumber":880,"Model":"EHGT17D-YM9ED","UnitType":1,"IsIndoor":true}]},"DiagnosticMode":0,"DiagnosticEndDate":null,"Location":119945,"DetectedCountry":null,"Registrations":445,"LocalIPAddress":null,"TimeZone":119,"RegistReason":"STARTUP","ExpectedCommand":1,"RegistRetry":1,"DateCreated":"2022-06-03T06:28:50.064Z","FirmwareDeployment":null,"FirmwareUpdateAborted":false,"Permissions":{"CanSetForcedHotWater":true,"CanSetOperationMode":true,"CanSetPower":true,"CanSetTankWaterTemperature":true,"CanSetEcoHotWater":false,"CanSetFlowTemperature":true,"CanSetTemperatureIncrementOverride":true}}],"Clients":[]},"AccessLevel":4,"DirectAccess":true,"MinTemperature":0,"MaxTemperature":40,"Owner":null,"EndDate":"2500-01-01T00:00:00","iDateBuilt":null,"QuantizedCoordinates":{"Latitude":48.8,"Longitude":10.1}}]
2024-02-27 07:39:33.340 - debug: melcloud.0 (8253) Got ATW device from cloud: 42490188 (MitsubishiGeodanWP)
2024-02-27 07:39:33.340 - debug: melcloud.0 (8253) Saving device data...
2024-02-27 07:39:33.498 - debug: melcloud.0 (8253) Created and saved ATW device 42490188 (MitsubishiGeodanWP)
2024-02-27 07:39:33.504 - debug: melcloud.0 (8253) Updated device data for ATW device 42490188 (MitsubishiGeodanWP)
2024-02-27 07:39:33.505 - info: melcloud.0 (8253) Connection successful. Starting polling (interval: 5 minute(s))...

Edit: Router sind FritzBox 6690 und 6591

[Black Thunder]

@galdreth Wenn in der Melcloud-App keine aktualisierten Daten vorliegen, kann auch der Adapter keine neuen Daten bereitstellen. Von daher vermute ich eher ein lokales Netzwerkproblem bei dir, das zufällig in zeitlicher Nähe mit der neuen Version auftritt. Dafür spricht auch, dass es nach einem Neustart des Wifi-Adapters wieder funktioniert.

Leider kann ich dir da aber auch keine wirklichen Tipps geben, da mir sowas bisher nicht untergekommen ist. Ist denn die Wärmepumpe weiterhin lokal erreichbar (Anpingen der IP), wenn keine Daten mehr geliefert werden? Vermute ja fast, dass die Verbindung zum Router abbricht.

EDIT: Eventuell auch mal im Ereignisprotokoll der Fritzbox die WLAN-An-/Abmeldungen prüfen.

[galdreth]

@black-thunder
Danke. Der Adapter ist lokal erreichbar im Netzwerk und ich kann auch keinen Verlust der Internetverbindung feststellen. IP-Adresse und Gateway bleiben konstant. Der Router ist nur 5m Luftlinie entfernt. Was mich wundert ist, dass es gut ein halbes Jahr ohne Probleme lief und erst mit dem Update des Melcloud Adapters in Iobroker fällt es immer zu festen Zeiten aus. Es ist als würde der Adapter beim Sendeprozess von irgendwas blockiert.

[Black Thunder]

@galdreth Du könntest mal testhalber auf die v1.3.6 zurückgehen (und da das Intervall auf 5min belassen) bzw. den Adapter vorübergehend ganz deaktivieren. Ich bezweifle aber, dass das wirklich einen Unterschied macht.
Das zugrundeliegende Problem besteht ja in der gestörten Kommunikation Gerät zu Cloud. Der Adapter kommuniziert mit dem Gerät selbst nicht, nur mit der Cloud.

[mchott]

Hallo .. ich habe seit heute mein Klimagerät an die Melcloud angeschlossen. Bevor ich zu Plan B übergehe habe ich noch eine Frage. Kann man dem Klimagerät einfach mitteilen, wie warm es wirklich im Raum ist. Dafür hätte ich ein paar Sensoren im Raum, die ich per ioBroker auswerten kann. Da wo das Gerät verbaut wurde misst es im Sommer und Winter einfach völlig falsch. Ich kann nur die Zieltemperatur setzen und nicht die Ist-Temperatur im Gerät überschreiben. (mal abgesehen davon, dass ich selbst auf der Basis der falschen Temperatur die Automatik nie verstanden habe)

[Black Thunder]

@mchott Nein, das ist so nicht möglich. Den Ist-Wert zu überschreiben bzw. ein Offset einzustellen, ist meines Wissens nicht möglich.
Ich habe es auch so gelöst, dass ich anhand externer Sensoren im Raum die Zieltemperatur dynamisch selbst bestimme und an die Anlage sende.

[mchott]

@black-thunder said in Test Adapter melcloud v1.3.x Latest:

ich anhand externer Sensoren im Raum die Zieltemperatur dynamisch selbst bestimme und an die Anlage se

Okay .. das in etwa war mein Plan B .. das Denken der Anlage abnehmen und indirekt steuern

[oxident]

@mchott @Black-Thunder Das heißt also,
ihr wollt z. B. 22°C im Raum,
Klimagerät meint, es wären schon 22°
und der externe Temperaturfühler zeigt 20°.

Ergo, ihr stellt die Klimaanlage auf 24°, oder?

[mchott]

@oxident so in der Art .. meine Klimaanlage wurde damals ungünstig positioniert, weswegen ich in der einen Ecke 24°C und in der anderen 20°C habe .. die Klimaanlage misst im Sommer in dem Fall 29°C und im Winter eher 17°C .. also alles völliger Mist und ich würde die Anlage so nicht einbauen.

Die Temperaturdifferenz behebe ich durch die Einstellung der Richtung, womit die Luft homogener wird und den Rest löse ich wie von dir beschrieben über eine manuelle Übersteuerung. Also ich schalte HEAT, COOL und VENT und eine Temperatur, die knapp über oder unter der gemessen liegt, bis es passt.

Soweit die Theorie, denn es funktioniert noch nicht alles perfekt, was im Wesentlichen an der schlechten Kommunikation zwischen ioBroker und MelCloud liegt.

[Black Thunder]

Als kleines Schalttagsschmankerl habe ich soeben eine neue Version 1.4.0 bei npm freigegeben (und sollte demnächst im latest aufschlagen).
Damit ist es nun möglich, in den Einstellungen den Abruf der Daten auch komplett zu deaktivieren, für all diejenigen, die dies sowieso nicht benötigen. Damit ist auch der Workaround, sehr hohe Werte beim Intervall einzutragen, überflüssig.

Bitte gerne Feedback, ob alles so funktioniert wie bisher oder ob es unerwünschte Nebeneffekte gibt.

[galdreth]

@black-thunder
Danke, es hat wie erwartet nicht die Lösung gebracht. Dann hab ich ein Ad-Hoc Wifi mit meinem Homeserver im Keller eingerichtet... gleiches Problem. Heute sogar mein Telefon per Wifi-Hotspot im Keller platziert... auch nix.

Folgende Symptome hat das Problem:

1. Letzte Kommunikation ist immer Sekunden vor 07:00 morgens oder 17:00 abends. Der Wifi-Adapter ist danach im lokalen Netzwerk und man erreicht auf ihm einn Login-Dialog per http. Die Fritzbox hatte auch keine zeitlich korrelierten Events. (Wifi An-/Abmeldung)

2. Dann muss man den Reset auf dem Wifi-Adapter ausführen, sonst kann man keine Werte auslesen oder Aktionen steuern. Danach gehts.

3. Noch eine Beobachtung: Nach Reset (selbst nach Power-Cycle aller Geräte) funktioniert die Timer-Einstellung in der MelCloud nicht (Egal ob Android oder über Web-App). Ich kann aber normal Steuerbefehle aus dem Netz senden und die Maschine macht was sie soll... hier der Fehler, wenn ich auf 'Timer' gehe: Hat das noch wer?
   

Das scheint doch eher ein rein interner Fehler auf Seiten der MelCloud zu sein?

[mchott]

@black-thunder Danke .. ich habe es gleich installiert und auch den Haken aktiviert .. scheint zu funktionieren.

Ich habe aber ein anderes Problem:

Im Raum verteilt sind Sensoren, deren Temp Werte ich einsammle und jede Minute läuft ein Skript, welches daraus die Einstellungen für das Kilmagerät ermittelt. Das funktioniert soweit. Per setState setze ich diese dann in den Objekten der melcloud, aber dann passiert damit eher nichts. Von der App aus reagiert das Klimagerät allerdings, also ist die Verbindung Klimagerät-Melcloud gegeben. Die Verbindung vom Adapter-Melcloud ist laut Log auch in Ordnung und ich erhalte auch die aktuellen Daten vom Gerät, also auch kein Auth Problem. Und vom Objekt her passiert auch manchmal was, aber eher selten, was mich eher verwirrt, weil es eben nicht immer nicht geht.

Irgendeine Idee? Zu schnell hintereinander? Muss ich noch was anderes setzen, damit er es sendet? Beim setState setze ich ack=false?

[Black Thunder]

@mchott Danke für die Rückmeldung.

Spontan fällt mir nix auf, warum das so nicht funktionieren sollte. Du kannst ja mal ein Debug-Log anhängen, wenn du die Temperatur setzst, die Änderung aber nicht in der Cloud ankommt.
Die Werte rundest du vor dem Setzen auf X.5/X.0°C? Könnte sein, dass "krumme" Werte dazwischen abgelehnt werden.

[mchott]

@black-thunder ich setze derzeit volle Integer als Wert, also 21.

setState('melcloud.0.devices.101371856.control.targetTemp',getState('0_userdata.0.uFactory.KlimaTempTargetUp').val,false);

Das sieht dann auch okay aus, wenn ich in die Objekte schaue. Das Log von dem melcloud Adapter ist immer recht schnell wieder weg, obwohl es auf debug steht.

Was ich aber eben gesehen habe ist, dass er z.B. den Wert auf 25 setzt und dann kommt ein Update von der Cloud und setzt den Wert auf 23 und dann kommt das ganze leicht aus dem Tritt, weil mit einiger Verzögerung dann doch der Wert aus der Cloud kommt und dann wieder auf 25 setzt, weil der Befehl durchgegangen ist.

Das kann sich dann also wild überlagern, wenn ich zu oft abhole oder zu schnell sende.

Wenn ich die Abholung deaktiviere .. wird dann nie abgeholt und immer nur gesendet?

[mchott]

@mchott gibt es ein "forceSend"? Wenn ich jetzt nicht mehr abholen würde, dann würde er ja erst etwas senden, wenn es sich nach seiner Erinnerung geändert hat, was ja auch nicht richtig ist. Er sendet ja nichts, wie ich es sehe, wenn sich der Wert nicht geändert hat.

[Black Thunder]

@mchott said in Test Adapter melcloud v1.4.x Latest:

@black-thunder ich setze derzeit volle Integer als Wert, also 21.

setState('melcloud.0.devices.101371856.control.targetTemp',getState('0_userdata.0.uFactory.KlimaTempTargetUp').val,false);

Das sieht dann auch okay aus, wenn ich in die Objekte schaue. Das Log von dem melcloud Adapter ist immer recht schnell wieder weg, obwohl es auf debug steht.

Das Log kannst du immer auch im Nachhinein auslesen. Z.B. direkt im Admin -> Protokolle -> Log herunterladen

Wenn ich die Abholung deaktiviere .. wird dann nie abgeholt und immer nur gesendet?

Es wird dann nicht regelmäßig nach aktualisierten Daten gefragt. Allerdings wird unabhängig davon nach jedem Sendevorgang die Rückmeldung aus der Cloud abgeglichen und ggf. die Werte aktualisiert.

@mchott said in Test Adapter melcloud v1.4.x Latest:

@mchott gibt es ein "forceSend"? Wenn ich jetzt nicht mehr abholen würde, dann würde er ja erst etwas senden, wenn es sich nach seiner Erinnerung geändert hat, was ja auch nicht richtig ist. Er sendet ja nichts, wie ich es sehe, wenn sich der Wert nicht geändert hat.

Ah ja, das könnte natürlich das Problem sein. Im Moment ist es so, dass nur ein Sendevorgang ausgelöst wird, wenn sich der lokale Wert in ioBroker geändert hat. Das führt natürlich jetzt zu dem Problem, dass man nicht mehr denselben Wert senden kann, obwohl in der Zwischenzeit dieser Wert potentiell längst veraltet ist.

Sprich bei "melcloud.0.devices.101371856.control.targetTemp" steht z.B. 21, in der Cloud/Realität hat sich der Wert aber (extern ausgelöst, z.B. durch Fernbedienung) geändert und du möchtest nun wieder 21 per ioBroker senden? Dann hast du Recht, das funktioniert im Moment so nicht. Könnte ich aber ändern, wenn gewünscht.

[mchott]

@black-thunder du sendest ja bei jedem Einzelwert einen kompletten Request, also alle Werte?

Ich habe jetzt mal ohne Daten abholen getestet und da läuft es sehr viel vorhersehbarer, wahrscheinlich ist dann der Konflikt zwischen setzen-holen-setzen-... der Grund für die Missverständnisse zwischen Kilma-Cloud-ioBroker

Option A Ich schreibe meine Werte und setze am Ende einen beliebigen Wert auf was komisches und wieder zurück, dann werden auf jeden Fall alle Daten am Ende konsistent übertragen. Eher ein Workaround.

Option B Es gibt ein "Bool" Field, welches ich aktiv auf true setze, dann wird gesendet und der Wert wird wieder auf false gesetzt. Oder ein virtueller Taster .. bin nicht so firm in ioBroker.

Option C Die Daten werden nie gesendet, bis ich auf einen Trigger klicke, was die Verwirrung in der Cloud senkt, da nicht jedes Mal viele Werte gesendet werden, sondern garantiert nur ein Request.

Option D Du hast eine sehr viel bessere Idee.

[Black Thunder]

@mchott said in Test Adapter melcloud v1.4.x Latest:

@black-thunder du sendest ja bei jedem Einzelwert einen kompletten Request, also alle Werte?

Nein, es wird immer nur pro Request der geänderte Wert gesendet.

Ich habe jetzt mal ohne Daten abholen getestet und da läuft es sehr viel vorhersehbarer, wahrscheinlich ist dann der Konflikt zwischen setzen-holen-setzen-... der Grund für die Missverständnisse zwischen Kilma-Cloud-ioBroker

Da sollte es keine Missverständnisse geben, da das Senden in Echtzeit passiert. So kann ein Konflikt mit den Werten aus der Cloud eigentlich nicht vorkommen, da der Wert dann dort mit dem gesendeten Wert überschrieben wird.

Option A Ich schreibe meine Werte und setze am Ende einen beliebigen Wert auf was komisches und wieder zurück, dann werden auf jeden Fall alle Daten am Ende konsistent übertragen. Eher ein Workaround.

Option B Es gibt ein "Bool" Field, welches ich aktiv auf true setze, dann wird gesendet und der Wert wird wieder auf false gesetzt. Oder ein virtueller Taster .. bin nicht so firm in ioBroker.

Option C Die Daten werden nie gesendet, bis ich auf einen Trigger klicke, was die Verwirrung in der Cloud senkt, da nicht jedes Mal viele Werte gesendet werden, sondern garantiert nur ein Request.

Option D Du hast eine sehr viel bessere Idee.

Bitte beschreib nochmal genau deinen Use-Case bzw. wie das Problem genau auftritt. Also welche Werte du wann sendest und wann es zu Diskrepanzen kommt. Am besten mit Debug-Log dazu.
So ganz kann ich das noch nicht nachvollziehen.

[Bernd1967]

@galdreth
Ich hatte ein ähnliches Problem mit dem melcloud Adapter und der Fritzbox.
Bei mir lag es an der Fritzbox. Dort hatte ich sehr vielen Geräten eine feste IP Adresse gegeben weil ich in der Vergangenheit Probleme mit dem internen DHCP Server der Fritzbox hatte.
Ich habe zum Test bei allen Geräten "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen" ausgeschaltet und siehe da, keine Verbindungsprobleme mehr mit dem melcloud Adapter.

[mchott]

@black-thunder hallo .. entschuldige die Wartezeit .. die hatte familiäre Gründe

Also .. derzeit habe ich die Abholung von der melcloud quasi deaktiviert (nur noch alle 12h) und es scheint sehr viel zuverlässiger zu funktionieren .. eventuell war es ein Timingproblem, also die Daten von der melcloud und meine Steuerung sind sich eventuell irgendwie in die Quere gekommen.

Ich habe am Code nichts geändert, sondern lediglich die Häufigkeit meiner Steuerung etwas gedrosselt, was ja auch Sinn macht bei der Trägheit des Systems und die Daten hole ich nur noch alle 12h ab, weil die Steuerung ja funktioniert muss ich jetzt eh nicht mehr ans Bedienpanel.