💬 Building a Raspberry Pi Gateway

[Rolo6442u]

I want to run this gateway with another networkid (RFM69) but can't find how to do this. The option --my-rfm69-networkid=105 in the config line is ignored. So maybe it should go in the mysensnsors.conf file, but what is the syntax of this option?
Thanks.

[mfalkvidd]

@rolo6442u where did you find my-rfm69-networkid? I don't think such an option has ever existed. If you found it somewhere we probably need to update that documentation.

Follow the instructions at https://www.mysensors.org/build/raspberry#advanced to set defines.

[Rolo6442u]

@mfalkvidd
I did not found it, I kind of made it up, following the syntax of other options.
Looks like there is no way of changing the ID at this moment for the PI gateway.

[mfalkvidd]

@rolo6442u ok. Well, making things up will usually not add them to the code ;-)

There is a way. Two actually. Set the define in one of the two ways described on the link I provided.

[Rolo6442u]

@mfalkvidd
Thanks, will take a look at that.

[mafe]

Is it also possible to read a sensor directly at the Raspberry Pi MQTT Gateway? I only want to send the status of a GPIO via MQTT. Is there an example code for this combination?

[alowhum]

Might be nice to know it compilation still seems to works fine on Raspbian Buster on a Raspberry Pi 4.

// Update: unlike on the Pi 3 I now had to activate SPI. Might be good to make that more prominent in the explanation now.

[mfalkvidd]

@alowhum to my knowledge, activating SPI has always been required, unless the user has already activated SPI by some other means.

Do you have a suggestion on how to make it more prominent that what it is now? Preferably without contributing too much to the pileup of notices that scare users - everything is super-important to at least 1 person.

[alowhum]

@mfalkvidd I don't know, perhaps mention it as something that has to be done upfront instead of something that might need to be done if there is an error?

I'm not having any luck actually getting the radio to work. I now noticed this warning during compilation:

g++ -MT build/drivers/Linux/GPIO.o -MMD -MP -DMY_RADIO_RF24 -DMY_GATEWAY_LINUX -DMY_GATEWAY_MQTT_CLIENT -DMY_DEBUG -DLINUX_SPI_SPIDEV -DMY_MQTT_CLIENT_ID=\"mygateway1\" -DMY_MQTT_SUBSCRIBE_TOPIC_PREFIX=\"mysensors-in\" -DMY_MQTT_PUBLISH_TOPIC_PREFIX=\"mysensors-out\" -DMY_CONTROLLER_IP_ADDRESS=127,0,0,1  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -c drivers/Linux/GPIO.cpp -o build/drivers/Linux/GPIO.o
drivers/Linux/GPIO.cpp: In constructor ‘GPIOClass::GPIOClass()’:
drivers/Linux/GPIO.cpp:53:18: warning: ‘%s’ directive writing up to 255 bytes into a region of size 48 [-Wformat-overflow=]
    sprintf(file, "/sys/class/gpio/%s/base", de->d_name);
                  ^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/Linux/GPIO.cpp:53:11: note: ‘sprintf’ output between 22 and 277 bytes into a destination of size 64
    sprintf(file, "/sys/class/gpio/%s/base", de->d_name);
    ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/Linux/GPIO.cpp:62:18: warning: ‘%s’ directive writing up to 255 bytes into a region of size 48 [-Wformat-overflow=]
    sprintf(file, "/sys/class/gpio/%s/ngpio", de->d_name);
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/Linux/GPIO.cpp:62:11: note: ‘sprintf’ output between 23 and 278 bytes into a destination of size 64
    sprintf(file, "/sys/class/gpio/%s/ngpio", de->d_name);
    ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[alowhum]

Could this be an issue?

./configure without any additional parameters gives:

[SECTION] Detecting target machine.
  [OK] machine detected: SoC=unknown, Type=unknown, CPU=armv7l.

The rest looks fine:

[SECTION] Checking GPIO Sysfs.
  [OK] /sys/class/gpio/export found.
[SECTION] Detecting SPI driver.
  [OK] SPI driver detected:SPIDEV.
[SECTION] Gateway configuration.
  [OK] Type: ethernet.
  [OK] Transport: rf24.
  [OK] Signing: Disabled.
  [OK] Encryption: Disabled.
  [OK] CPPFLAGS: -DMY_RADIO_RF24 -DMY_GATEWAY_LINUX -DMY_DEBUG -DLINUX_SPI_SPIDEV 
[SECTION] Detecting init system.
  [OK] Init system detected: systemd.
[SECTION] Saving configuration.
  [OK] Saved.
[SECTION] Cleaning previous builds.
  [OK] Finished.

Same thing happens with the dev version

[mfalkvidd]

Yes, if the configure script cannot detect which hardware to use, compilation failure could very well be the result.

[swedchef]

Hi All

I'm just venturing into this world of building my own sensors - but perhaps i am a tad late? Two months since last update.. Typically me - showing up to the party when everybody else has left.

My main issue is, i am running the Raspberry Pi 4 - and when trying to build (i've tried both the development and master builds) i get from 4 (master build) to A BUNCH (development) of errors. First of all, the autodetect of SoC does not work for me either (just like @alowhum, and with the same warnings), and when using --help the actual SoC is not listed either, so should i just assume it does not work for Raspberry Pi 4?

Is there any chance the 4 will be supported soon?

Just a note - i can actually complete the configure and then make - but unfortunately i just get a TSP error when trying to fire up the radio.

Hope i can get this working as it was the main reason for upgrading my RaspberryPi version 1 to a version 4 :man-facepalming:

Thanks in advance for any and all help!

[mfalkvidd]

Thanks for sharing your experience @swedchef

From the problems reported by users (you included), it seems like the rpi4 is quite different fom the earlier rpis. To add support, the following ingredients are needed in one person

• person needs to have sufficient knowledge and skills to figure out how to support the rpi4
• person needs to have sufficient time to do the work
• person needs to have a rpi4
• person needs to be sufficiently interested/motivated to do the work

It seems like, so far, we haven't found this person (or this person hasn't found us).

[phildefer]

Re: 💬 Building a Raspberry Pi Gateway

Hi all,

i compile with success the gateway in Raspberry PI 4 (with some code modification)

this is not perfect.. but it works.

if someone wants to try, i upload the gateway compiled with this options :

--my-transport=rf24 --my-gateway=ethernet --my-port=5003

https://gofile.io/?c=fRxeF7

[Anticimex]

@phildefer could you please share what you changed? The security concerned might not be comfortable running a binary with unspecified changes that manages their home automation setup. Especially not a project supposed to be open source.

[mfalkvidd]

@phildefer would you mind sharing the code modifications that were needed?

[phildefer]

@mfalkvidd @Anticimex : yes i sharing the code perhaps this week end. I need to find time to make a PR to GITHUB
As I said, my code may not be as clean as you'd like, but it works.

[patrikr76]

Hey all,

I got the same problem as @swedchef and saw the warnings @alowhum mentioned.
Simply upping the buffer that is declared in GPIO.cpp solved the warnings and made it compile without issue but the radio still won't work.
Maybe it has to do with the soc not being detected, as mentioned, and that the pin positions on the new soc are different from previous ones.

@phildefer, weekend has come and gone buddy. Patience is a virtue some do not have. :)

Edit: So looking a little more through the files today i see that configure looks for the soc type in /proc/cpuinfo and funnily my raspi 4 reports a BCM2835

[mfalkvidd]

@patrikr76 I beleive @phildefer pushed the code 4 days ago. See https://github.com/mysensors/MySensors/pull/1353

Something has seriously mangled whitespace in the modified code, but apart from that it looks good to me, but I am not that familiar with the rpi code and I have not tested it myself.

[patrikr76]

@mfalkvidd said in 💬 Building a Raspberry Pi Gateway:

@patrikr76 I beleive @phildefer pushed the code 4 days ago. See https://github.com/mysensors/MySensors/pull/1353

You are correct.
@phildefer, thank you.
There were a couple of minor warnings about indentations and the buffer size i mentioned earlier fixed by upping the declared buffer in GPIO.cpp. Not sure if that is a good fix or not, the warning goes away though.
A few other warnings looks like this:

In member function ‘char* MyMessage::getString(char*) const’,
    inlined from ‘bool transportSendWrite(uint8_t, MyMessage&)’ at ./core/MyTransport.cpp:987:2,
    inlined from ‘bool transportRouteMessage(MyMessage&)’ at ./core/MyTransport.cpp:560:40,
    inlined from ‘void stUplinkTransition()’ at ./core/MyTransport.cpp:252:29:
./core/MyMessage.cpp:284:17: warning: ‘char* strncpy(char*, const char*, size_t)’ output may be truncated copying between 0 and 25 bytes from a string of length 25 [-Wstringop-truncation]
    (void)strncpy(buffer, this->data, this->getLength());
          ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Not sure how to fix those.

Edit: Forgot to mention, it seems to be working though.