-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More time sensitive Agents #157
Comments
Hey @qedi-r, I'm glad you're building on Huginn! I've been thinking about how to make Huginn closer to real-time for a while. I think it would make sense to allow Agents to cause immediate propagation when desired. This would enable many interesting new uses. I'm happy to advise you on how to build it this. We should definitely write good RSpecs to demonstrate how it works. Maybe you should update
and add Once that's done, it should be easy to modify Event similar to how you suggest:
Finally, change
The primary change is the I think this will work transactionally, causing full propagation only for downstream agents of the one creating the event. I haven't tested this, though. The reason we need full propagation for those Agents is so that we don't accidentally bump their |
If I understand what you've written in event.rb in your comment, it sounds like you'd prefer propagate_immediately to be set on the agent that generates the event, but I think it should be set for agents that receive the event. That way, if you have Agent A and receiving agents X, which has propagate_immediately set and Y, which is something that has it's own schedule, X would run immediately after A, but Y should wait around. If A has to set propagate_immediately, we might end up breaking user's schedules. |
Well, propagating immediately shouldn't break anyone's schedules because propagation happens every 1 minute anyway. I agree that it conceptually makes a bit more sense to be set on the receiver. That could be accomplished in Event like this:
I'm trying to figure out if there are any race conditions that can occur by having |
I see one problem with this in case there are loops in the system (which might not be detectable in the graph). In that case if Agent A produces event E sent to agents B and C, and B triggers back A, you would run in a loop A-B-A-B and starve C. |
Good point. |
Is this working for you okay? |
I'm currently writing some agents to work with my home automation infrastructure and have a working implementation for a Phillips Hue agent that I will probably add a pull request for soon. In this kind of environment, though, the 30s-1m delay between agents as they pass events from one to another is much too long. Currently, I've modified Huginn's event code to immediately kick off linked agents as follows:
But I would probably also need to add some sort of locking to make sure we don't accidentally schedule the immediate event twice, once with this code and once with the scheduler.
What I don't know, being new to the codebase is if there are any unknown problems to this approach?
The text was updated successfully, but these errors were encountered: