💬 Sensebender Gateway
-
The hardware supports both NRF and RFM69 at the same time, they share the same SPI bus, but has separate chip select lines etc.
Unfortunately the MySensors library doesn't support multiple transports, so this time it's the software that limits things.
@tbowmo
The fact, that MySensors doesn't support more then one radio, was the reason for me not to order the sensebender gateway.I am working on a gateway⁄controller based on an arduino due, which supports at least up to 3 serial gateways via hardware serial. It handles ID and time (synced with ntp) requests and does pub/sub to mqtt with readable topics.(inspired by the old mqtt client gateway)
-
@tbowmo
The fact, that MySensors doesn't support more then one radio, was the reason for me not to order the sensebender gateway.I am working on a gateway⁄controller based on an arduino due, which supports at least up to 3 serial gateways via hardware serial. It handles ID and time (synced with ntp) requests and does pub/sub to mqtt with readable topics.(inspired by the old mqtt client gateway)
-
@FotoFieber this is a software limitation. Hardware wise I do not see why Sensebender GW cannot handle two (nrf24l01+ and rfm69/rfm95) GWs at the same time
@alexsh1
The question is: will the software restriction be solved? If not, I do not care if it is a software or a hardware restriction. :) -
Well, you need to hack the core anyways, if you want to accomplish your goal.
You could also help out with the core development, so we can get support for multiple transport on one gateway ;)
@tbowmo
No, I don't have to hack the core. I use the serial API. From an architectural point of view, I don't see the need to change anything in MySensors. A serial controller can be built for under 20€ Including the radio. Why should I add complexity to support more than one radio support with one cpu in MySensors, if I can have the functipnality with the abstraction layer of the serial API? Please keep MySensors s simple as possible. -
@tbowmo
No, I don't have to hack the core. I use the serial API. From an architectural point of view, I don't see the need to change anything in MySensors. A serial controller can be built for under 20€ Including the radio. Why should I add complexity to support more than one radio support with one cpu in MySensors, if I can have the functipnality with the abstraction layer of the serial API? Please keep MySensors s simple as possible.@FotoFieber simple for who? Simplicity also involve maintenance and code complexity. What about testability and regression testing? Nobody gets paid for maintaining mysensors.
-
@tbowmo
No, I don't have to hack the core. I use the serial API. From an architectural point of view, I don't see the need to change anything in MySensors. A serial controller can be built for under 20€ Including the radio. Why should I add complexity to support more than one radio support with one cpu in MySensors, if I can have the functipnality with the abstraction layer of the serial API? Please keep MySensors s simple as possible. -
But you ditched the sensebender Gateway, as it doesn't support multiple radios at the same time? Now you are saying that you would keep it as one radio per gateway?
This doesn't make sense :)
@tbowmo
Maybe the design of the sensebender gateway doesn't make sense to my architectural viewpoint.... -
@alexsh1
The question is: will the software restriction be solved? If not, I do not care if it is a software or a hardware restriction. :)@FotoFieber This is a question for the MySensors dev team. Sensebender can handle both radios. Currently, there is a software restriction.
-
@tbowmo
No, I don't have to hack the core. I use the serial API. From an architectural point of view, I don't see the need to change anything in MySensors. A serial controller can be built for under 20€ Including the radio. Why should I add complexity to support more than one radio support with one cpu in MySensors, if I can have the functipnality with the abstraction layer of the serial API? Please keep MySensors s simple as possible.@FotoFieber No, you do have to hack the core if you want both radios to be handled properly, i.e. to handle message queues with corresponding radios. For example, sending a message is done via rfm69 only and not via nrf24l01+
-
The architecture we use would place this kind of situation to the controller to solve. One gw per network. So one gw for nrf and one for rfm.
HW is cheap, and library should be kept simple.Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
The architecture we use would place this kind of situation to the controller to solve. One gw per network. So one gw for nrf and one for rfm.
HW is cheap, and library should be kept simple.@Anticimex
One gateway per radio, that is what I think is best. :+1:What I try to do, is to implement a controller with arduino due for up to three serial gateways. If there would be a solution for ethernet&rfm69 I may not have invested time in this. :laughing:
-
Well sensebender GW supports rfm69 with ethernet ;)
-
Well sensebender GW supports rfm69 with ethernet ;)
@tbowmo
Yes, that is really nice. :+1:My other goal was to have a new MQTTClientGateway, as it existed with MySensors 1.1 (which is not only a gateway, but a controller too). It would have been really painful to add it to MySensors 2.1.x, as I would have to patch core files. It is much easier, to throw hardware at it. :laughing:
-
Well sensebender GW supports rfm69 with ethernet ;)
@tbowmo More practical question. I have received the GW and it already has MySensors 2.1.0 software. Excellent service by Itead. Can you please help me how to map LEDs in the GW sketch? I can see that they are connected to pins 38, 41, 42, 39, 40 as LED1, LED2, LED3, LED4 and LED5. Thanks
-
@tbowmo More practical question. I have received the GW and it already has MySensors 2.1.0 software. Excellent service by Itead. Can you please help me how to map LEDs in the GW sketch? I can see that they are connected to pins 38, 41, 42, 39, 40 as LED1, LED2, LED3, LED4 and LED5. Thanks
you should be able to use LED_BLUE, LED_GREEN etc. defines (or even just LED_1, LED_2..) in your sketch, to access the different LED's on board the gateway. That is, if you are using the SenseBender GW hardware support files in arduino (installation instructions are here https://github.com/mysensors/ArduinoBoards)
Also, look at the board definition files, located here https://github.com/mysensors/ArduinoHwSAMD/blob/master/variants/mysensors_gw/variant.cpp
and here https://github.com/mysensors/ArduinoHwSAMD/blob/master/variants/mysensors_gw/variant.h -
you should be able to use LED_BLUE, LED_GREEN etc. defines (or even just LED_1, LED_2..) in your sketch, to access the different LED's on board the gateway. That is, if you are using the SenseBender GW hardware support files in arduino (installation instructions are here https://github.com/mysensors/ArduinoBoards)
Also, look at the board definition files, located here https://github.com/mysensors/ArduinoHwSAMD/blob/master/variants/mysensors_gw/variant.cpp
and here https://github.com/mysensors/ArduinoHwSAMD/blob/master/variants/mysensors_gw/variant.h -
You might be able to compile with the standard arduino zero BSP files. But the IO mapping is not the same at all.. I have swapped some pins to make routing a bit easier. Also the SPI channels are configured a bit differently than the standard arduino, if I remember right. So I will advise to use the mysensors gateway BSP files..
