@alowhum
Some more personal remarks (hard to do in english, to be honest):

Reading your postings wrt. to the DS18B20 things and your enhancement proposals, I can somehow understand about your frustration. (The DS18B20 and BME280 I also use, so this is a part I can follow to some extend, other than a lot of other hardware you mentioned). I also suffered from changes in the libs that made it not to easy to get things going (routines from "the outer world" becoming private and so on). And some of the comments on your code in the mentioned thread are rather hard to understand or interpret.
As I also did one pull request in the past, I also know how high one's frustration tolerance has to be just to get through the necessary organisational process (including copyright questions and so on).

But: this is necessary stuff to go through... And the devs here are really doing a great job in quality assurance - at least imo.. But to be honest: It also took me quite a lot of time to find out, how difficult it in fact is to choose the right compromise between a lot of aspects.

Just one example: Your last proposal wrt. to temperature was to use BME280 as a future standard. Did you ever use more than 2 temp sensors on one node? Most likely not, as this is more or less only possible using the 1wire protocoll (I have around 25 of them on 3 nodes using 7 Pins as data lines).
And BME280: Try to compile the last version of the lib for ATMega328: It's broken... And the lib consumes way more memory (ok, to be honest: most likely most is for doing forecast calculations).
So please keep two things in mind:

• The two of us just see a small part of the world and are just about to start understanding how things really fit together. So going just one step after the next is best way to do. Don't be to eager, good ideas will find their way in the MySensors or Arduino code base.
• There are a lot of forums around, but only a few have the spirit you find here: If you ask your questions, you will most likely get a friendly answer that could bring your project forward!

So a big thank you to all the devs and mods around here! Great job!

To start, first decide what controller software you want to use (https://www.mysensors.org/controller).
Then you can start to built a sensor network (https://www.mysensors.org/about/network).
Typically, all the sensors are based on small Microcontrollers (most of the time: ATMega328). For using ESP8266-based Hardware (NodeMCU), you'd better have a look at other projects like ESPEasy ot Tasmota. Most controller sw supporting MySensors will also have a kind of plugin for these type of (ESP8266-) firmwares.

In my original HW setup I also used D4 for Servo and D5 for 1wire, but any pin should be ok AFAIK.

Additional remark: powering the nRF24 through the 3.3-PIN on Nano may cause trouble; use at least a capacitor as recommended in "Build".

Hi SuperKris,

most likely, there is not a definite answer to your questions.

First a very good point for a lot of info around the nrf's: https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo

I personally got best results using the PA+LNA-Versions and additional base modules, power sourced through 5V with PA-Level set to max.

This is the standard-level which is used as long as there is no explicitely defined other level. This is the standard mechanism using the myconfig.h settings. Keep eyes open, as this is defined to LOW e.g. in the GW-Sketch...

MAX will also work with the non PA+LNA-Boards, but keep in mind using this setting also means higher power consumption, so soucing the NRF through Arduino's 3.3V-PIN might not work.

@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...

You seem to send the temp messages under a different ChildID than it is presented:
presentation takes "1", send uses "0". You have to allign that, e.g. by using

send(msg.setSensor(i+CHILD_ID_TEMP).set(temperature,1));

But as long as there's just one DS18B20 doing that dynamically doesn't really make sense. Using the defined message structure (MyMessage msgTemp...) could make things more transparent.

Also there's no sending command for voltage. So why do you expect the controller to receive also voltage?

Found this some days ago: https://github.com/mysensors/MySensors/pull/1142

Adding these changes to a 2.3.0-alfa base seem to make a big difference in reliability .

So if there's other users having similar problems: please make also some testing of this patch.

You will get further updates and some more info on my recent setup, so far: Thanks a lot for all the ideas and hints to improve things!

seeers created this issue in mysensors/MySensors

closed Avoid data array overflow #1142

@sebex At least some answers to your questions:

• As Nano and Uno use the same processor, there's no big difference between the two, besides the fact Nano's just USB powered...
• when talking about environmental data, you'd perhaps also like to have a look at BME680; it doesn't deliver CO2 directly, but the delivered restults ale partly calculated on this.
• Most newer (I2C-) sensors seem to work at 3.3V internally, so when powered directly at 3.3V, you might be able to avoid losses due to a voltage regulation
• DS18B20 Modules sometimes come with a resistor, so you'll have to desolder that in case you want to use more than one on the 1-wire bus; "naked" sensors might be more suitable, e.g. if you want them to be mounted closed to a metal tube to measure water temps => depends on your needs.
• ZigBee and MySensors are completely different worlds. (Apart from RS485) MySensors itself is capable of building a mesh network.
• In general, MySensors can be used with any meassuring equipment as soon as there exists an arduino library for the hardware - the rest ist just "packing" the measured values in a MySensors-compatible format for data exchange with te controller. Searching the web for CO2+arduino+sensor gives at least some results. Better ask for experience with a specific sensor and avoid starting "multiple" questions threads like you did here.

@ben999 If you do node-to-node communication, the message does not necessarily need a controller; it is routed through the lowest common repeater node (this might be the gateway). Eg. if you have two nodes 5 and 6 that are communicating over node 4 with the gw, the gw may not even see the message.
Coding then looks like this:

send(SisternodeMsg.setDestination(MY_SISTER_NODE_ID).setSensor(CHILD_ID_SISTER_TEMP).set(temperature, 1));

In case you use a controller, you would have to map the values through the controller's functionality (eg. put temperature value #2 from node 5 to value2100 on node 6 so this can be requested from node #6 using it's own ID and child ID 100 - V_VAR2.

In both cases you have to code appropriate receive()-functionality.

There was a rather small note in the 2.0.0 changelog about the introduction of before().

Btw: Another functional routine (preHwInit() (?)) may have been introduced also with 2.1.1 (?). But until now, all of my sketches and tests got along without this preHwInit() functionality. But imo the new structure is pretty good: before() is helpfull to initialise SPI devices on same bus as nRF24 and to collect relevant info like the number of DS18x20, setup() is now also good to send info you only need once (e.g. the Dallas-Chip-ID).

The rest is - at least afaik - not really documented well, but most examples (if you use the updated ones) will work (apart from the DS18x20 example, where other - external - code changes made some parts tricky to use.

I made some working sketches for the Dallas Sensors some time ago based on some ideas I found here in the MySensors forum; they mostly should still work (exept for the change of getConfig() to getControllerConfig()). If you are interested: here .

Kind regards

Question: Is your gateway connected to some controller software?
Afaik, MySensors won't work propperly without, this is what you experience as problems with ID request and transport layer reset. Though there are options to get around that, I'd strongly recommend to involve one.

@Adam-Slowik Afaik, 0xFFFFFFFFF isn't garbage but the request to the controller to assign a ChildID. So most likely, you have to create a special handler for such a request (comparable to what nRF24 or RFM drivers most likely do) or make sure to assign a ChildID in every node's sketch manually (similar to RS485 transport layer usage).

@OliverDog You may have a look at https://github.com/sidoh/esp8266_milight_hub. It uses basically the same hardware as a normal MySensors Wifi-GW and is able to receive and send (most) of the MiLight-Codes. I'm using the MQTT interface offered by the hub not only to translate MiLight-V5-protocol type of remote codes not only to control V4-protocol type of rgbw bulbs (which seems to be close to your request), but also to set shutter levels or even control my mpd... Obviously, this nees some additional coding on controller side (FHEM in my case).

@projectMarvin He might have meant https://www.candlesmarthome.com.

There might be several other cloud-free open-source solutions for home automation. I personally use FHEM which "since ever" has been designed to run cloud-free and allow local control to virtually everything. (downside is: most likely as most (all?) other controller software offering a lot of options and allowing to control everything, you have to learn the underlaying language or at least a lot of specific commands/script instructions). Despite that, if you absolutely desire to involve one of the big internet players, it's possible to also add voice control options (to some extend also locally afaik; I' more focused on automation to overcome the needs for active user interaction).

Beside that: +1 to the statements of @projectMarvin .

Recently came across this here: https://github.com/saghonfly/shrdzm/wiki. Seems to be an ESPNOW-based solution (MQTT-GW is also available).
Did no testing on that at all (I'm more tending to use wires/RS485 for homebrew stuff ), but if you are insisting in using these nasty Espressif-mcu's, this might be intresting...

@jocke4u said in Parallel Gateways:

In what sense do you consider RPi-Ethernet-GW to be more tricky than Arduino-Ethernet-GW?

See https://forum.mysensors.org/topic/11145/started-with-mysensors-and-about-to-give-up-some-feedback for a lot of people reporting about running into problems. Imo it doesn't make much sense fiddling around with a very complex base (Pi) when using a very simple base (arduino@serial or LAN-gateway) is possible...
Just my2ct.

Wrt. the other stuff, I completly agree with @mfalkvidd's approach; at first sight it seemed you were looking for a drop-in replacement. But as soon, as you want to update nodes also, different channel is a very good idea.

@jocke4u In which aspects do you expect problems?
Imo it's just a question how your controller deals with that. E.g. in FHEM, one can switch around IO devices without problems, and a second GW will just "see" all messages beeing send. Note: Using both to controll anything most likely isn't a good idea.
I assume, you already know the PI-GW-variants to be more tricky than ordinary serial WiFi or ethernet gateways?
If you are about to build up new hardware, you may have a look at https://forum.mysensors.org/topic/11135/something-s-cooking-in-the-mysensors-labs/10 as well and e.g. prepare the hardware to use different type of transports as well in the future?

Good to her you found that point .
Imo you'd better change also your receive functions to not react on "ack" messages (via "else" prior to message.type-comparison).

@FullMetal Pls add also code from node 4.

In general:

• if you want also info from node 5 to be sent to your controller/gateway, you have to add a second (normal) send command.
• wrt. to how node 4 reacts on the messages, you may better use sth. like a toggle logic.

@FullMetal Imo, you have to specify all send-settings in one line, e.g. like this:

send(buttonMsg.setDestination(MY_SISTER_NODE_ID).setSensor(CHILD_ID_RESET).set( button[i] ? "1" : "0"));