Plans?

[electro_bob]

I have been working on my own framework for sensors, I am almost in the same place, but with a lot of shortcuts.
Considering the community around MySensors, I thought there there would be a greater opportunity to grow if we work together, so I could dump mine and continue developing here.
However, there are some things that I want from the framework, so I am interested developers' intention to include such features in the near future:

1. Serious multiple gateway support, with both multiple local and multiple over the internet gateways.

2. Making the code C/CPP rigorous, not Arduino style so it can be used on different platforms which offer full HW control and code transparency.

3. Message merging so multiple messages can be carried over the same packet. Custom, on the fly defined types is a bonus.

4. Gateway-less operation.

5. What are the long term commercial intentions of mysensors?

Of course, I can help implement 1, 3 and 4 and quite a few other features I am interested in, but number 2 is quite blocking, as I have no intention to spend time upgrading each new release, so it is more of a change that has to come from the core developers.

Cheers!
Bob

[hek]

Welcome to the community @electro_bob. I'll try to answer your questions.

1. Could you elaborate a bit more on what you mean bu multiple gateway support and how you'd like this to work from a radio network and controller perspective. As the radio network is setup today all messages must have a destination which defaults to (0 = gw). If you introduce more "gateway" nodes, you must address all messages to multiple destinations in your sensors. From the controller perspective it might be easier to handle multiple gateways (serving one radio network) but it is still something that needs to be developed support for. Most controllers support multiple gateways already, but they can only handle one separate sub-network each.
2. We are slowly moving to a less Arduino-like library. You can build MySensors in toolchains like platformio and on multiple platforms AVR/SAMD/Linux/RPI. It's always a balance of ease-of-use (we are pretty keen on letting beginners have a easy start) and how to server the more advanced users. But we can all agree on that the Arduino IDE sucks big time.
3. Yes, this topic has been discussed a few times over the years. If you decide to help out on this one, keep in mind we still want to have support for signed messages (which needs a bit of headroom in the payload to be useful), repeater nodes and still keep the footprint of the library (including buffers for assembling/queue messages) at a reasonable size, especially on low-end MCUs. Also, the number of use-cases for large messages is pretty few in the HA-type-of applications we're focusing on. The only thing I can think of right now is sending large IR-codes which usually don't fit in one message.
4. That is already possible. But one of the node has to repeater to relay messages if you want to send between nodes because of the tree-topology the radio network forms. Only repeaters/gateways keep a routing table to sub-nodes.
5. We will always be a open source project with a GPL-x license.There's also a commercial option for companies not willing to share their sensor code or core-changes back to the community/customers. They will have to support the MySensors project financially instead. But there has been zero "sales" so far

[electro_bob]

Thanks for the reply. Here is what i have in mind in more detail:

1. Say i have a NRF24 and a RFM69 and RS485 communication locally. Another WiFI gateway at work with some sensors to check if the colleague is really watering my plants as it should. Gateways should have a link (IP prefferably) with eachother, so that any node can send a message to any node. This should not go through a central controller. So far i am splitting the node address space into few ranges, each one for a GW, but would say gw.node.child would be a better addressing scheme.
2. If you were to import the arduino project in something like atmel studio (or eclipse or other ide) that copies the arduino core sources and then the libraries and tries to compile in regular c/cpp, this would not work. My desire is to be able to nicely see and change the underlining HAL layer, because i really like to juggle with HW resources. Having used the SAM lately with ASF i find it way more intuitive to change things like which SPI to use. Platformio is of no interest, since it is still calling the underlying arduino compiler with it's special programming language.
3. Some things are simple: find a way to say what is the light level as well as that motion is triggered. Fundamentally i want to create new types on the fly, independent of the middle library. At an extreme case: upon startup a child should say: my packet contains a boolean, a float and another byte. The controller software then gets 3 channels. Basically, I want to get rid of the strictly defined V_ and S_ and create definitions based on fundamental data type. Between this implementation and yours there are a lot of other combinations and where the compromise falls it is hard to say.
4. I built some nodes, using nrf24: dimmer, dimmer with rotary, motion, button and gateway. It seems that if the GW disappears, even adjusting the dimmer from the rotary is chaotic and mostly does not work. The motion sensor also does not seem to resume normal operation should the GW resume functionality. Might be some small changes required, but based on request 1, ideally any node should be able to communicate with any node, on any GW, and in the case of a missing GW, the core functionality should stay (be able to control the light with the local switch).

I hope this makes things a bit more clear now. Thanks for the support.

[electro_bob]

Any thoughts on this?

[hek]

1. I stopped reading after reading the first point in your answer (was late night here then). Do you actually mean the ethernet gateways should be able to form some kind of network by their own (with other physical networks on top of things) without any central point or "master" orchestrating things? Well, that is out of the MySensors scope at the moment. We're talking of simple hardware here (ofter without SSL capability).
   I would say a controller at each location is a excellent solution. You can setup tunnels between your networks and have them synchronising whatever data between each other as you'd like. What I'm saying is that this is not the responsibility of the MySensors library.

2. The Arduino IDE uses the standard avr/gcc below the surface. There's noting wrong with the compiler itself.

3. New protocols (both over the air and gw->controller) has been discussed in several threads over the years and there's lots of ideas on improvements and simplifications. I'ts not gonna happen until we make a major release as this would break all the controller integrations. Big bang changes is always hard in a loosely coupled project like this with developers from 25+ controller projects.

4. Depends on how the sketch is implemented.

[electro_bob]

Thanks for the reply, @hek.

1. Maybe here we can take things one at a time. For a first step, would building the GWs as MQTT allow connections through a broker such that multiple GWs will work?

2. "Arduino compiler" is bad shortcut name. I meant that there is some transformation arduino does to the code before it reaches the gcc compiler. This is what i want to avoid and have my code work with gcc directly, even if using arduino core/libraries.