Domi04151309 / HomeApp

HomeApp is a small and easy to use smart home app with a simple framework.
https://f-droid.org/packages/io.github.domi04151309.home/
GNU General Public License v3.0
106 stars 24 forks source link

[Feature Request] Seperate device availability and commands in the SimpleHome API #12

Closed P-a-t-r-i-c-k closed 2 years ago

P-a-t-r-i-c-k commented 4 years ago

Describe the solution you'd like A previously connected device might not change available commands often. Reloading a potentially large list of command at each connect could be avoided.

A clear and concise description of what you want to happen. I think a separate "heartbeat" message could be used instead of loading the full command list if an device is opened. This message would only need to contain some basic information over the available command, to make sure there are no changes. If there is a change, the full command list has to be called, resulting in a performance penalty. However, this probably happens way less frequently so often only a short message is needed to check if a device is available.

Additional context - An approach to this heartbeat message could be a time stamp of the last change. However, this might be more difficult to implement on the device side. An easier option for microcontrollers might be to log the last boot time. HomeApp could then check if this time is more recent than the last full command list and act accordingly. - Including a (basic) hash of the command list in the heartbeat. This is probably easiest on the client side, however not all microcontrollers might like this? - Including some basic metadata. A few basic details, for instance command, character count and ascii value sum could be sufficient to assume an unchanged list.
Domi04151309 commented 4 years ago

Most microcontrollers don't know anything about the time except the amount of milliseconds since boot. But the idea is good.

P-a-t-r-i-c-k commented 4 years ago

Most devices will probably have access to the internet, so NTP might be usable? However, an additional dependency to a third party might not be ideal.

Using time passed in milliseconds as you mentioned would be better I think, since an occasional overflow would only cause one additional request.

Domi04151309 commented 3 years ago

But then there could happen an integer overflow or a reboot and the timestamps with milliseconds wouldn't work anymore.

Domi04151309 commented 2 years ago

Closed because of implementation issues