Will MySensors work for me?

[gohan]

Hi. Well, for rs485 people had mixed results, most common issues seems to be rs485 interfaces or cabling/termination problems. There is a user testing some can interfaces in place of rs485 and first impression is good, but we are still waiting for a longer term review.
Mysensors would most likely work since it will allow to just swap the communication layer from your current setup without too much effort once you understand the basics

[rejoe2]

@stefferd (I'm most likely the RS485-user @gohan is reffering to).
Imo, the key question is how to deal with the TRV's. If this is more or less independent C-code already adopted for the microcontrollers you are working with, you most likely will not have to big efforts to migrate your entire project to mysensors.

So I'd recommend to start first in understanding how MySensors in general works and how it's integrated into your controller software. Use something rather simple like a temp or PIR sensor node (or a combined one). As communication layer I'd start with RFM69 (868MHz). Should be sufficient to get much better results than in 2.4GHz WiFi.
Then you could try to replace Node 6 as a first step of migration. Next Node 4 with additional repeater functionality, in case Node 5 is to far from your controller/gateway to make the communication directly. For this, you won't need any RS485, this just replaces the wifi connection and one single RS485 connection.

As your current wired solution also works to your needs, you may stop there or - decide then to also sowitch over to MySensors with this part.
Remark on RS485: I at this moment would neitherblame the RS485 chips nor the implementation in MySensors to be the origins of my troubles. It just took me very long to understand all the parts that can affect communication. So if you already have a working electrical layout of RS485 lines, most likely this will just work when switching just the used lib for communication. At least one user in the FHEM forum has recently installed a line with 4 nodes running reliably for several weeks, and there seem to be a lot guys out there with similar results. But no guarantee...

[Stefferd]

@gohan && @rejoe2 Thanks for your replies,

As for the TRV's, i basically stripped down an existing TRV to the motor and mechanics, and built an arduino-based pcb with H-bridge and shunt to take over control. I wrote a simple library that handles the logics and reads the voltage over the shunt, so yes - it's arduino based and with implementable code code.
I have enough hardware to completely rebuild a test situation in the setup i want. I would really like to avoid using 868MHZ harware due to the unencrypted nature.
Wired RS485 systems and an understanding of the electronics behind it is also no problem. The big issue is in fact everything behind a wireless bridge in my current situation.
I will setup a new server instance with OpenHab, and start playing around with MySensors.
Thanks for your great input!

[gohan]

Mysensors can handle both rfm69 encryption and also signing

[alexsh1]

@gohan that’s true. The only problem is memory in case of atmega328p. I noticed with encryption and sighting not much of it left....

[Anticimex]

@alexsh1 encryption on rfm69 is cheap as it is handled in hardware.

[alexsh1]

@anticimex Yes, you are correct. I have just double checked

Sketch uses 24236 bytes (75%) of program storage space. Maximum is 32256 bytes.

and

Sketch uses 24098 bytes (74%) of program storage space. Maximum is 32256 bytes.

With and without encryption.
However, on many nodes I cannot include signing /debug etc as I exceed memory usage. I suspect that if I want to take it to the next level, I need to refactor libs I am using or just use an AVR with more memory

[gohan]

there is also option to use optional signing for nodes if you need to debug first. What libraries are you using that are so big? It would be nice to have some more development on STM32 but NRF5x chips are drawing a lot of attention

[Anticimex]

@alexsh1 yes, or debug signing first, to validate it works and when confirmed, disable debug and turn on your other functionalities. If they need debugging, debug them without signing as it is unlikely signing will have any impact on other libraries. It does not affect data sent or received "outside" the library.

[alexsh1]

@anticimex That's exactly what I do debug signing first and then debug are going as soon as testing is done. And unfortunately even that may not be enough. I do not want refactoring libs.

[Anticimex]

@alexsh1 signing fits fine on atmega328p. Just comment out any calls to your libraries and the linker will garbage collect any code drawn in by them. Once you confirm your security is operational, disable the debug prints alltogether and add your library calls.
Of course, if you have space issues even then, there is not much to do but optimize the code.