Mod

Hi @matias_sams, welcome to the MySensors community!

The answer to all your questions is yes. However, the more logic/code added, the harder it will become to create bug-free code, and troubleshooting also becomes harder. Our general recommendation is to start simple and then add more logic step by step.

@sergio-rius I'm not completely sure what you want to achieve, but a gateway can also contain sensors. Could this be a way to go?

Hi @артем-тихонович, welcome to the MySensors forum!

For the NRF24, the same defines as for normal sketches are used. Documentation: https://www.mysensors.org/apidocs/group__RF24SettingGrpPub.html
The defines can be added to the Raspberry Pi gateway by following the instructions on https://www.mysensors.org/build/raspberry#advanced

I have not heard about anyone using the Cubieboard but hopefully someone else has. The information provided on https://www.mysensors.org/build/orange might be useful if the Cubieboard is similar to the Orange Pie.

oh, and in case you haven't already, see the ./configure --help text about the most common NRF24 defines; you might not need the advanced build options.

@superkris nice project! You should submit it to hackaday!

@ッanteroッ this forum deals with MySensors, while your question does not seem to be related to MySensors at all. There are likely better forums to post such questions.
My impression is you received a faulty LED strip, with bad connections making some parts light with a different color than expected. I suggest you take it back to the shop.

@grumpazoid in general no, the sensors will just communicate with the gateway.

But some controllers do not support dynamic id assignment over mqtt so you might need to define MY_NODE_ID.

@grumpazoid MySensors uses a gateway to connect the MySensors network to the rest of the world, which is often a controller.
There are various gateways supporting e.g. serial or ethernet, but there also are MQTT gateways (see the xxxMQTTClient examples here ).
These gateways are clients, so they connect to an MQTT broker elsewhere to publish and subscribe their messages.

also from last
byteorder handling is build in
library allows to choose any order
I select bigendian because this is natural to my major MCU - STM8
on little endian platforms (like STM32, ESP8266 and ARM64) data is automatically translated

for esp8266 i made an universal bridge application
it can be used for both:

• single node, esp8266 is running a final application. on the photo above my thermostats to measure room temperature, report it and to send ON/OFF commands to heaters

• bridge. can be used to connect other type networks wirelessly to application server. UART is used for this + json translation. currently this is implemented to connect heating controllers located on each floor

main and failover servers can be configured
also each node is configured to handle from one to a few network segments. this allows simple routing from application server back to node
esp8266 is using ArduinoOTA and zero hardcording.
after fresh programming esp creates AP and smartphone can be used to preconfigure a node
any updates are keeping configuration except major updates there stored structure can be affected

application server is also support MQTT translation
etc. it looks like a routing between my network and MQTT server
RX/TX adresing are mapped to MQTT topic while message is translated into JSON:

made a few steps forward

launched ESP8266 node & bridge and STM32 bridge and TCP/IP router based on linux (orangepi)
bellow is my working example
list of supported platforms:

• STM8S/IAR
• STM32F0/Keil - draft
• ATMEL/Atmel studio - draft
• Arduino ESP8266
• Arduino STM32
• Linux/g++

i;m working on 2 libs. first is to handle platform dependant things. second is platform independant smart devices network
regardless platform and regardless communication hardware the framework allows to transfer messages using RX/TX notation with 16 bit global addressing.
Addressing is organized as 4096 segments where 4094 are 15 node segments each and 2 segments are for broadcadsting

framework allows to connect potentially absolutelly different communication hardware
currently i'm running:

• simple one wire (1 wire signal + 2 wire power) network
• wifi based nodes
• twisted pair connected ethernet devices

bridge between different types of network is organized on TCP/IP application server running currently on linux
etc. potentially allows to connect network segments regardless physicall location, only internet connection is required

why i'm doing this? mostly for fan but also to implement 2 principles:

• application layer to be independant from hardware and transport. message format is universal and is the same regardless platform and communication hardware. Addressing is also universal. Application should not take care about intermediate specific, this is handled by other components
• avoid a central unit. each device can communicate with each device. the only central component is application server. but is is very simple, robust and reliable. failover is supported

My example: