Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Roy van de Water
    @royvandewater
    nvm, I tried to draw it out, and it looks like the short-term fix may not work :-(
    Roy van de Water
    @royvandewater
    Virtual Devices Setup
    Roy van de Water
    @royvandewater
    I’m going to see if I can add the features for the long term fix today
    The idea is that you’d have a virtual device with a statefull broadcast.sent subscription to the sensors
    This means that all broadcasts sent by each sensor comes in to the virutal device via the device’s broadcast.received port with a route that looks like this:
    route: [
      {from: "abc…", to: “123…", type: “broadcast.sent”},
      {from: “123…”, to: “123…”, type: “broadcast.received”}
    ]
    we the have an (unimplemented) message forward setup on the virtual device, which would look something like this:
    Roy van de Water
    @royvandewater
    {
      "meshblu": {
        "version": "2.0.0",
        "forwarders": {
          "broadcast": {
            "received": [{
              "type": "meshblu",
              "emitType": "broadcast.sent"
            }]
          }
        }
      }
    }
    Then, like in whiteboard picture I posted earlier, all broadcasts from the two virtual devices (abc… and def…) would be reemitted by the virtual device (123...)
    you would then be able to drop the node in the designer and have it emit the abc… and def… broadcasts
    Virtual Device in Designer
    Roy van de Water
    @royvandewater
    The message format would look something like this:
    {
      "metadata": {
        "route": [
          {"from": "123...", "to": "flow..", "type": "broadcast.sent"},
          {"from": "flow..", "to": "flow..", "type": "broadcast.received"}
        ],
        "forwarded-routes": [
          [
            {"from": "abc...", "to": "123...", "type": "broadcast.sent"},
            {"from": "123...", "to": "123...", "type": "broadcast.received"}
          ],
          [
            {"from": "123...", "to": "flow..", "type": "broadcast.sent"},
            {"from": "flow..", "to": "flow..", "type": "broadcast.received"}
          ]
        ]
      },
      "data": {
        "devices": ["*"],
        "payload": {
          "foo": "bar"
        }
      }
    }
    Then the broadcasts could come from the real devices (abc… and def…) via any protocol and they would still appear in the designer
    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