Closed cru8602 closed 3 years ago
Thank you for opening the issue. In fact, I had not thought about the plans at all. I just released a new beta which contains the needed changes.
I'm happy if you try it and give a feedback.
Works very well. The plans are now part of the global context and can also be filtered in the node output. 👍 THX!!
While we are talking about the scope of the global context: can the homeegrams and the users object also be added to the global context?
In principle, both are possible. However, I can't think of any use case for saving the homegrams. Which use case did you have in mind?
I've avoided stroring the entire user object for security reasons. If you are interested in the presence status, it probably makes more sense to write only this state and the user id to the global context.
If the homeegrams would be part of the global context the information wether a hg is beeing enabled/played or not could be used as condittions in other flows. the same goes with the users object. But I have to agree that there are very little keys in the user object that are relevant so it baisicly goes down to "id" and "is_present".
Ok, storing the homeegrams makes sense in this context. I will add this soon.
I would still not want to save the users. I could provide a sample flow for saving selected user attributes on the wiki after the release.
I have just released version 0.9.0-beta.1. The homeegrams are now also included.
I just installed the beta.2 homeegrams and plans are now included in the global context and the node seems to work fine 👍
Thanks for testing. I have just released the 0.9.0.
At the moment messages containing plan (heatingplan) information can not be filtered in the API node and the plans object can not be storred in the global context. msg oft the type plan can only be recieved when all filters are deactivated. Is it possible to add these?