iobroker-community-adapters/ioBroker.fronius

[Enhancement] delete old states

Closed this issue · 8 comments

Please check whether its possible to delete states from pre2.0.0 release which are no longer used / supported.

Please also add a short section at readme listing those states and their replacement

Listing the states is not that easy as it always depends on the system configuration. Not sure what is the best way. Either just inform the user he should note the states which are recorded by a history adapter and then delete all the states by himself or deleting the old states...

Ok,
States might depend on system config. But those states should be identical with old or new adapter. Changes due to new release could be
-) change sto base (folder) structure
In this case the old foleder should be invalid in all cases
-) changes due to added or re,moved prefix/postfix (Adapzter has attribiute PW, old state was myPW, new state is PW so all my* could be deleted.

Another solution could be to add a config button "cleanup states" which removes alls states the adapter has not "seen" since startup or have net been used since a specific timespawn.

One thing I notes from forum is, that the complet tree Fronius.0.powerflow has moved to Fronius.0.site. so powerflow.* could be deleted I guess.

Comparison from V1.1.3 and V2.0.0 object structure. Thanks to the effort to @c1olli
fronius.xlsx

@mcm1957 I thought about implement to parameters on config. NotifyUnusedObjects and DeteteUnusedObjects. These parameters are set as days not used till the action is happening. Does this make sense for you? If yes, could you give me a hint how to get the object tree of the adapter to check the ts of the state? Thanks

Sorry for the late answer - I missed this open issue.

I do NOT think that is is necessary to add configurable options to remove unused objects. Personally I would not even remove states which are no longer filled due to changes in connected devices. Deleting a state might cause loss of historic data - so I think it should not occure automatically at a regular base.

The reason for this issue was that some states where moved to another tree. As far as I see this refers to powerflow.* was moved to site,. So deleting powerflow. during or after Upgrade would be OK as part of the upgrade. Bit feel free to document this change only and close this issue.

Regarding the question how to get TS:
As far as I know every getState call should return the complete state info. Timestamps of last change should be part of the object. But I did not chck it.

I have made a comparison what parameter changed in the following file, Tab Gegenüberstellung. I think it would be ok to just provide this information on the upgrade. I just dont know how to present that information best... Just as text in the release notes or as part of the README file as a link to xlsx or text file.
fronius.xlsx

Text in Readme or link to textfile is ok.
Link to excel file is suboptimal as you need extra software to read.

I just added the information to a document linked to the readme. The user should manage the move manually to ensure the history states are properly handled