@Alan-Sales it seems the project is abandoned. But I have it, so please use this link:
https://www.dropbox.com/s/b0qls8a251ol4tc/MYSController.zip?dl=0
@tekka maybe you could share the code somewhere? Maybe someone else could make a use of it or develop it further?
Hello Everyone!
As some of you may know, me and my friend @slawkiwala are working on a project of a wired home automation system based on RS485 and MySensors. From the beginning we were quite serious about it and now we managed to launch a crowdfunding campaign.
Though probably the majority of you here are interested more in wireless hardware than in wired, maybe our project will be useful for at least some of the members of this community. If so, then please support and share our campaign!
More info can be found on the campaign page
PS First revisions of the designs, which are now taking part in the campaign, were published on openhardware.io.
PS2 Important information about shipping: Crowd Supply pre-clears customs and pre-pais VAT for packages shipped to all EU countries, Switzerland, Australia, and Canada. This means backers from these countries will not have to pay anything more than the pledge level cost + the international surcharge and also will not have to pass any customs control.
Let's dig out this thread a little. I am a person who's started my own MySensors based hardware project (GetWired, I wrote about it somewhere on this forum), so I probably can be described as an involved user. Somehow it happened that I haven't become an active user on this forum, on one hand I didn't have to write here, because all problems I've encountered were described earlier. On the other hand, I didn't receive much interest after publishing anything (openhardware designs, project related posts).
In my opinion, MySensors with nRF24 has very strong competition, especially taking into consideration the low reliability of this radio. It's easier and better to buy cheap Shelly or other Sonoff. Using nRF52 would help a lot, but it is much more complicated, at least in my opinion.
Second thing is the development of MySensors has slowed down a lot (last commit March 20th). If so, there is not much to discuss here.
Third thing is connected to the development of my own project. Me and my colleague managed to put it on a successful crowdfunding and build a community elsewhere. All this with no support from this community and especially from the MySensors "authorities". I don't want to complain, I just think such initiatives could meet with higher interest from everyone involved in the development of MySensors, because it would be mutually beneficial.
Hello,
This module is finally available to buy assembled. Now our project is complete, you can run the whole RS485 system after some shopping here, on openhardware.io. See details on the project pages.
Cheers,
feanor-anglin
Few topics before I posted about our wired home automation project based on MySensors:
https://forum.mysensors.org/topic/10921/getwired-rs485-mysensors-home-automation-modules
Please have a look 
In case of any questions, please feel free to ask me.
Ok, I've made some digging on Home Assistant GH and found out it's not a bug but a feature, but they just haven't put any info about the change to their documentation:
https://github.com/home-assistant/core/issues/62703
Long story short, to use the notation “[Sketch name] [Node id] [Child id]”, there should be no sensor description in presentation().
This is supposed to work with “[Child description]” notation:
present(NOTIFY_SENSOR_ID, S_INFO, "Child description");
And this with “[Sketch name] [Node id] [Child id]” notation:
present(NOTIFY_SENSOR_ID, S_INFO);
Hi there! Recently I've been working on a new feature for my GoWired project, which is about configuring modules with text messages using notify.mysensors Home Assistant service. The whole idea seems pretty powerful to me, but I encountered problems with the notify service.
Home Assistant documentation states 2 notations for setting the notification target:
I started with the second one, because it gives an opportunity to precisely specify the target: node ID + child ID, while the first one leads to sending the notification to all nodes with a given child sensor description. But despite many attempts and trying many notation variants I only managed to make the first notation work. The second seems not to send anything at all. Is there anyone here who's encountered this issue?
I've asked, because I cannot test it right now and thought maybe someone has done it before. In this case I will test it myself next week. Right now I have some code that compiles, so maybe it will also work 
Referring to multimessage feature, I don't see any application yet (maybe I need to understand it better). More important to me is auto ID assignment for RS485 which seems to be also finally merged. Great!
As far as I understand it, there is 10 different set functions for all kinds of payload:
Source: https://www.mysensors.org/apidocs/classMyMessage.html
And now, the set (const void *payload, const size_t length) seems to me as a variant of set function which should give me an ability to create any kind of payload. I see it like this:
send(message.setType(messageType).setSensor(sensorID).set(payload, length));
So, do I understand it correctly? And if yes, then how to use set (const void *payload, const size_t length) to create any payload, from binary to float?
Just a quick question: any hints/examples on how to use it? I haven't found anything while I'm afraid it can be helpful to me.
Nice idea @gieemek, I will definitely implement something similar. But what about the gateway? I often experience problems when sending messages to multiple nodes at a time through Home Assistant.
@Alan-Sales it seems the project is abandoned. But I have it, so please use this link:
https://www.dropbox.com/s/b0qls8a251ol4tc/MYSController.zip?dl=0
@tekka maybe you could share the code somewhere? Maybe someone else could make a use of it or develop it further?
Very important feature, actually I can't understand how it is still missing in MySensors. Ultimately there should be just one more percentage value with a proper name added to the same device ID. Separate ID is not a good idea, because of the reason you presented. As you say, it seems quite difficult this way, but nonetheless this should be a goal here. Using VAR1 is a good and fully functional workaround though. I'm looking forward to see your code.
Do I understand correctly, that you are planning to port MySensors to Zephyr OS?
@NeverDie I perfectly understand how it works and that it is impossible to reach everyone with a post. I've wrote about it here.