arjenhiemstra / ithowifi

Itho wifi add-on module (ESP32 wifi to itho I2C protocol)
GNU General Public License v3.0
170 stars 29 forks source link

trigger status update when changing settings via API/MQTT #247

Closed ikruglov closed 1 week ago

ikruglov commented 3 months ago

Hi,

First of all, thanks for this project!!

Problem statement

  1. update api.html?vremotecmd=auto
  2. request api.html?get=ithostatus
  3. the fan-info value in (2) is not updated immediately, but after "Update frequency" (60s by default) which is set in "System settings".

I'm wondering if it's possible to trigger an internal status update when api.html?vremotecmd=... is received (or any other speed modifications API).

An alternative is to reduce "Update frequency" but this is not ideal as it may cause extra (over-) load for the ventilation unit and the add-on.

P.S. I didn't check behavior in MQTT, but I assume it's the same. P.S.S. I'm happy to hack with code myself, but I'll need a bit of your guidance.

arjenhiemstra commented 3 months ago

Hi, thx for the issue! The only known way to get the info sooner is the decrease the update value. The info needs to be obtained from itho firmware, I do not know any other way to retrieve this info.

ikruglov commented 3 months ago

The info needs to be obtained from itho firmware, I do not know any other way to retrieve this info.

Sure. This is expected. I'm talking about triggering internal update right after processing vremotecmd command. Essentially, one need to call the same function/procedure which is trigger by schedule at the end of vremotecmd command.

arjenhiemstra commented 3 months ago

you could useapit.html?get?lastcmd for this. I just noticed that it fell put of documentation somehow but it is still in code for the WebAPI: https://github.com/arjenhiemstra/ithowifi/blob/2c554d5c0de098dc65df4e87d9ed043d4d604a4a/software/NRG_itho_wifi/main/tasks/task_web.cpp#L603C16-L603C22

and the MQTTAPI on the "lastcmd" subtopic

ikruglov commented 3 months ago

Thanks for the suggestion. But I don't think it works.

what I do is the following: terminal #1

$ watch -n 1 curl -s http://itho.local/api.html?get=ithostatus`

terminal #2

curl -s http://itho.local/api.html?vremotecmd=auto; curl -s http://itho.local/api.html?get=lastcmd

what I expect: ithostatus shows me fan-info: auto right after command finishes in terminal 2

what I get: ithostatus updates the value of fan-info after dozens of seconds. Effectively, when the periodical update happens.

arjenhiemstra commented 3 months ago

"get=ithostatus" retrieves data directly from the itho firmware, one can expect other values but we are limited to what the itho firmware reports back. There is no way to influence this behavior I'm afraid...

ikruglov commented 3 months ago

after some digging into the code, I found the right combination:

curl -s http://itho.local/api.html?vremotecmd=auto; curl -s http://itho.local/api.html?vremotecmd=31DA

so, as I said before, the key is to trigger an internal status update; i.e. to send 31DA command which internally calls sendQuery31DA which forces an update of ithoMeasurements vector which queries ITHO status and provide up-to-date information for get=ithostatus.

In my opinion, these routines should happen as part of handing any fan speed updates. But, vremotecmd=31DA should work as well.

arjenhiemstra commented 2 months ago

I'll add sendQuery31DA and sendQuery31D9 to the queue after each i2c remote command. That should fix it I think

stale[bot] commented 2 weeks ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.