Another way of organizing variables

[Zeph]

Here is another conceptual approach.

[Zeph]

In the current conceptual architecture, I am beginning to understand why there is resistance to the gateway ("dumb switching gateway") retaining or understanding anything about nodes other than their addresses. It is conceived as a simple nearly-transparent channel between the Nodes and the Plug-in.

• The plug-in knows a lot about nodes, but knows as little as possible about the gateway; at most the gateway might assist encoding as the plug-in tells it.
• A feature like binary OTA value encoding to the nodes would need to be handled by the plug-in and the nodes

In the alternative conceptual architecture, the plug-in communicates with the gateway ("smart gateway as proxy"), which in turn makes use of the nodes to provide bidirectonal services to the plug-in.

• The plug-in know about the WSN and its gateway as proxy, but knows as little as possible about how the gateway and nodes communicate.
• All the plug-in knows about nodes is what the WSN gateway wants or needs it to know
• A feature like binary OTA value encoding to the nodes only affects the gateway and the nodes, and is hidden from the plug-in

Neither approach is "right". They have tradeoffs. I'm currently suggesting that the alternative approach may prove advantageous in the course of time, but I have no proof of that.

---

An example implication (tradeoff):

• In the current approach, sending only binary values OTA to nodes would mean changing every controller plug-in to somehow know the "payload type" needed for each node, and use an enhanced serial format (etc) to tell the dumb gateway how to binary encode the value. Until all plug-ins are updated, we can't support the new all-binary format. No one team is likely to maintain all plug-ins or stay in sync.

• In the alternative approach, changing the OTA binary encoding would not require any changes to the various controller plug-ins, at that would be a private thing between the gateway and the node (the node would probably inform the gateway when it joined the network).

Suppose a new sketch for a particular node extended the calibrated range of a sensor (eg: sound, light..) or actuator and needed to use 2 bytes OTA rather than one. The controller plug-in would never need to know. The smart gateway would automatically adapt the next time the revised node joined the network, so its code and config would not need to change.

[Zeph]

About Plug-ins.

I see the weakest link in maintaining and developing the not-just-Vera MySensors system over years to come as being the per-controller plug-ins.

I think the core system can be made very solid - all programmed in C++ for known hardware where we can pretty much "control the vertical and horizontal" (sorry, old US TV reference). We have a lot of control, and the whole community is potentially available to review things like the 1.4 upgrade.

But the plug-ins fragment the community's resources. Writing or maintaining a plug-in requires not just general MySensors knowledge but also developer-level knowledge of a given HA controller and it's plug-in architecture. Plugins may often use a different language than C++, and run on different hardware and OS's. Inherently, only a fraction of the community is likely to have the knowledge and time (and incentive) to work on any given plug-in. So it's likely that some plug-ins are going to get stale, and be slow to get updates - compared to the core system.

Given that prospect, my tendency is to make the task of the plug-in relatively simple, and stable with as few changes as possible even as we evolve MySensors per se to new versions. The more we can hide logically unneccessary information about the nodes and network from the plug-ins, the less our future development of the core will require that every plug-in writer "keep up" with it. (Or the less we get fragmented by maintaining and backporting to old versions of MySensors in order to support the plug-ins that haven't been updated yet).

Just my judgement call, not a fact.

[daulagari]

@Zeph What I see on your architecture pictures are three/four levels/components:

• Nodes
• The Gateway
• Home Automation Controller X/MySensors Plug-in

I agree with @Damme that it is better to keep the gateway simple but also share your concern of the plug-ins taking up valuable community's resources.

Why not take the plug-in (partly) outside the Home Automation Controller X and make it a component between the Home Automation Controller X and the Gateway, let me call it "Home Automation Abstraction Layer" (HAAL) or "MySensors Abstraction Layer" (MAL).

The HAAL/MAL should:

• Have a clear defined interface towards the Home Automation Controller
• Do as much as possible that is common for the different Home Automation Controllers
• Be able to do all communication with the Gateway/Nodes
• Be preferably a plain-C module so that it can be linked with the Home Automation Controller or linked with the Gateway code

For the interface towards the Home Automation Controller we could have a look at existing interfaces like the OpenZwave interface, the ZigBee Home Automation standard or even a new defined interface as long as it is good documented and using it you do not have to known anything about the MySensor internals.

[Zeph]

@daulagari said:

Why not take the plug-in (partly) outside the Home Automation Controller X and make it a component between the Home Automation Controller X and the Gateway

That's kind of what I proposed a while back - with the provision that I suggested that one option could include running on the same hardware as the gateway.

The idea was indeed to abstract the MySensors wsn.

Thanks for the pointers to OpenZwave and Zigbee as possible interface candidates (or inspirations).. That will take more study.

Does anybody know how widely these interfaces are already implemented in Home Automation control software? For example, if we had an OpenZWave interface to the MySensors WSN, would we be able to easily connect may open and/or closed source HM contollers to it?