Closed gedw99 closed 3 years ago
So most things (at least handlers that don't require state) start here:
If a node is a rule, and conditions are met, then we run actions:
which publishes a Notification to NATS.
If the notification hits a user node, it publishes a message to NATS.
And then we send out a message here:
So the flow is:
Point (NATS) -> Rule -> Action -> Notification (NATS) -> Msg (NATS) -> Twilio
The fact that this is not obvious means I have work to do.
For processes that process points and require state (modbus, upstream, etc), I have implemented them in the node directory. Eventually, the twilio stuff will require state (voice calls with callback handlers, etc), so will eventually need to move there.
I've debated if Notifications and Messages should be points instead of custom data structures. They are transient data structures that don't need to be synchronized (at least for now), so for now they are separate for simplicity. If we make a point more flexible, then it might make sense to convert notifications and messages to points. The advantage of this is then everything automatically gets storied in influx (or whatever timeseries store is active) without any extra work, and at some point things like notifications and messages may need synchronized between instances if we run multiple peer instances in the cloud for redundancy.
Keep asking questions and pointing out thing that don't look right -- there is a lot of work to do yet :-)
closing, re-open if needed.
https://github.com/simpleiot/simpleiot/blob/master/data/message-service.go
So then to add a real Twillo Service where did you do it ?
I am trying to learn the patterns