Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    ryanrdl
    @ryanrdl
    @royvandewater where would you configure this forwarder? Why not be able to have a node you drop to subscribe to specific topics in MQTT (or AMQP)? If you subscribed to # (or *?, never remember) you would get all incoming messages.
    Roy van de Water
    @royvandewater
    @ryanrdl one of our focuses is around device centric permissions and whitelists. The concept of virtual devices was created to encapsulate the management of permissions for a group of devices. One of the reasons we want to do it that way is that it will allow users to take advantage of Virtual Devices outside of the designer, as well as inside of it
    As to subscribing to MQTT and AMQP topics, we don’t really use the MQTT and AMQP brokers in the traditional sense, since it doesn’t allow us to inject ourselves in the middle to perform whitelist validations on each message delivery
    Instead, Meshblu acts in the role of message broker
    This is also what allows us to broker the messages in a cross-protocol way
    Our MQTT and AMQP adapters just present a protocol specific API into the Meshblu broker
    ryanrdl
    @ryanrdl
    So when I am dropping a node on the designer I really shouldn't think of it as an individual sensor but possibly a collection of similar sensors?
    @royvandewater would that be accurate? I think I need to shift my mental model a bit.
    Roy van de Water
    @royvandewater
    That’s correct, if your intention is to have your flow act on information broadcast from a group of sensors
    If you only want information from one sensor, then the easiest way is to drop that sensor directly into the flow
    I hope to have a version of Meshblu with broadcast.received -> broadcast.sent forwarding out soon (couple of hours)
    then we can see if this model will work for what you’re trying to accomplish
    ryanrdl
    @ryanrdl
    right now I am looking at machines that have a bidirectional protocol being able to send information and then communicate back (like if you are monitoring temp and that specific machine goes out of spec and needs to be sent a stop command)
    Roy van de Water
    @royvandewater
    And you want to create a single flow that manages a group of devices, where each individual device both broadcasts sensor data and is capable of receiving a ‘stop’ command?
    a simplified flow would look like this:
    vDevice->condition->vDevice
    ryanrdl
    @ryanrdl
    correct... I would like to be able not have to configure every individual machine but for ever Fuji XYZ machine, they can all use a common flow
    Roy van de Water
    @royvandewater
    gotcha

    k, so the

    device->condition->device

    flow works out of the box as-is

    with the virtual devices, we need just a little bit more logic in the flow, and some functionality in Meshblu
    Specifically, we need to expose that forwarded-routesproperty I mentioned earlier
    ryanrdl
    @ryanrdl
    @royvandewater cool
    Roy van de Water
    @royvandewater
    so that we can see which real sensor caused that virtual device to re-emit the sensor data, and tell the appropriate device to stop
    Roy van de Water
    @royvandewater
    Example Flow
    This is what I’m picturing the flow would look like
    Roy van de Water
    @royvandewater
    The message forwarding stuff has been pushed to Meshblu
    One thing that’s missing is that we don’t include the forwardedRoutes in the request headers on webhooks, so I’ll need to add that tomorrow
    Then, I think we just need to expost request metadata in the flow engine (so you can reference {{metadata.forwardedRoutes}} and that example will work
    We talked through the permissions, and it gets a little more complicated if we want the sensor/devices not to know anything about the flow. In that case, the flow doesn’t have permission to send messages to the sensor/devices, so we’ll probably want to send the sensor/device a message as the virtual device
    This will require using an HTTP Post node instead of a Meshblu node for now :-/
    I’ll see if I can publish a demo flow of what I mean, after the metadata stuff has been added to the engine and the forwardedRoutes have been added to webhooks
    ryanrdl
    @ryanrdl
    @royvandewater is there any concept of "startswith", "endswith", "contains", etc... like the equals type nodes? If not, a general regex node would be useful.
    Jade Meskill
    @iamruinous
    Yeah that would be helpful. For now we do expose lodash in the function node so you can use those functions there.
    Roy van de Water
    @royvandewater
    @iamruinous yeah, but I think it’s an old version of Lodash that doesn’t have docs up anymore :-(
    I’d like to update it to the latest, but who knows how many flows will break if I do that?
    @ryanrdl all those are available, so you can use _.startsWith for now. You’re right though, we should definitely have those nodes in the designer
    Roy van de Water
    @royvandewater
    The forwardedRoutes has been added to webhook forwards
    just need to add support to the flow engine
    Roy van de Water
    @royvandewater
    @ryanrdl The flow engine changes have been deployed
    I have an example flow with a sensor behind a virtual device that emits temperatures. The flow sends it back a stop command when the temperature exceeds 75
    I’ll make a blueprint
    The hard part is setting up the virtual device & sensor permissions, since the Octoblu UI doesn’t support meshblu 2.0 permissions yet
    I can walk through it with you sometime, if you like
    Jade Meskill
    @iamruinous
    @royvandewater maybe a script that creates the devices with permissions?
    Roy van de Water
    @royvandewater
    @iamruinous yes, I have most of that already, but it’s hard to understand what’s going on.
    Jade Meskill
    @iamruinous
    just use comments. #problemsolved
    ;-)
    Roy van de Water
    @royvandewater
    I created a project that does all the setup