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

youtube really seams to tear "everyone" to "fast and easy solutions". I personally really hate that IoT stuff talking to the www without asking and therefore try to avoid whatever can't be flashed with own firmware for "offline" use.
Atm. I'm fiddling around vith voice control via Rhasspy. Really impressive project, btw. (I'm not to deep into all the details on that, but controlling my lights, shutters or media stuff works really great, even without any online service provided by any of the big players; just a service with relatively small resouŕce footprint on a dual-core server built ages ago!).

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!

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

@mfalkvidd said in Zigbee gateway with support for multiple vendors?:

I spoke too soon. One of the SNZB-02 (the one in the attic) stopped reporting. Before it dropped off, it reported a lqi of 105 and 100% battery. [...]
So so far, the robustness of the network doesn't seem to be as good as I hoped. Maybe Zigbee is not the right solution for projects.

As already mentionned:
@rejoe2 said in Zigbee gateway with support for multiple vendors?:

So basically, imo in most 3.0 cases with "simple devices" like sensors and bulbs the question is not whether a specific device can be integrated, it's other issues that matter:

• the quality itself. I had some very disappointing buys, e.g. an rgbw bulb from Lidl with painfull white light color, noname Xiaomi-motionsensor clone (battery empty after some hours?), same with Sonoff motion sensors, that additionally didn't work at all...

Especially the SonOff stuff seems to be disappointing. For the rest, it mostly depends on the stability of the network itself (amount of "always powered" router type devices).

But finally, I still prefer using (wired) MySensors for some of the things that's still in the pipeline to come somewhen in time ...

@NeverDie said in Zigbee gateway with support for multiple vendors?:

@rejoe2 Yipes! Thanks for your detailed reply. it does sound a lot more complicated than I had supposed. My naive approach to making a gateway probably wouldn't work then.

You're welcome!
Originally I started quite similar and had the idea to write a plugin for FHEM that uses the output of a CC253x directly (similar to what openhab seems to do), but finally gave up before even really beginning...
At that time, the ConBee II was the only powerfull USB adopter available, so I decided to switch to deconz from zigbee2mqtt (CC2531, ConBee wasn't supported at that point in time). I still don't like the strict split between "sensors" and "lights" resulting in 2 or more "devices" in the long-time existing "bridge"-implementation in FHEM for one and the same hardware (e.g. a plug with power measuring will be 3 devices in the end), but that's not really that important to change horses again (zigbee2mqtt will use the full hardware address, if you refrain from using "friendly names" (a real euphemism, btw.))

@NeverDie

Is sending the raw received Zigbee 3.0 packet to MQTT sufficient?

Although I've done quite a lot of funny "practictioners testing" with different ZigBee stuff, I'm not very deep into all the details. So here's something like a personal summary wrt. to the technical aspects - more from a pure consumer view though:

• using a "simple MQTT interface" might be possible, but most likely processing the data isn't fun at all;
• with Tasmota (https://tasmota.github.io/docs/Zigbee/) there's already a ZigBee2mqtt implementation running on ESP8266/ESP32 base. I personally didn't like that solution, especially as there had not been any "over time consistency" in the messages. Once you "rejoin" the ZigBee mesh with a device, this one gets a new identifier - no possibility to track which one it has been in the past; (additionally the json structure of the messages is basically a mess, too, imo)
• especially CC253x is very limited when used as coordinator, there's better silicon available for that purpose. For diy solutions it's a well-known chip, see here and mysensors-ZigBee-diy-discussion.
• wrt. to "coordinator software" using one of the long-term established solutions imo is the easier way than developing one your own. Choose between deconz, zigbee2mqtt or (perhaps, no experience with that) openhab and you're done. The later two afaik can use the "raw serial stream" of quite a lot of common devices - this is e.g. why I originally bought the "Lidl Starter Set": The bridge has not only a powerfull coordinator chip on board, but also a LAN interface and might be used together with them after beeing hacked (no link at hand, sorry).

Obviously, doing a really structured job on coordinating (and visualizing) the mesh network requires some more computing power, so this will exceed at least what's possible with an ESP8266, but as one has typically running a more powerful box for the automation itself, running e.g. deconz or zigbee2mqtt on top of that doesn't really make a difference.

Apart from that:

• What's also very obscure is the question, if "bindings" are possible between specific devices (direct communication between two devices without controller software interaction). And - even if that's possible - if it's really used when building "groups" within the controller software...
• As soon as there's enough "router" devices, the network itself seems to be rather stable. In the beginning, I sometimes had trouble especially with "tradfri" bulbs that had to be unpowered from time to time (could also have improved by newer firmware or changing the location they were used, didn't investigate much in that) (same with one specific Xiaomi temp/hum-sensor).

@NeverDie said in Zigbee gateway with suuport for multiple vendors?:

On the one hand, it says, "Currently 2195 devices are supported [....] or is it one of those prickly things where it looks the same but [...]

According to my personal experience (although using deconz) almost all the "ZigBee 3.0" stuff bought from local Discounters and/or chinese marketplaces had been working just from the start or been integrated timely (no experience with blind controllers though!). I and some other FHEM users did some (German) writeup on that here.
So basically, imo in most 3.0 cases with "simple devices" like sensors and bulbs the question is not whether a specific device can be integrated, it's other issues that matter:

• the quality itself. I had some very disappointing buys, e.g. an rgbw bulb from Lidl with painfull white light color, noname Xiaomi-motionsensor clone (battery empty after some hours?), same with Sonoff motion sensors, that additionally didn't work at all...
• you have to take care to buy the right hardware variant: There's tons of relay devices, but how to wire them? Some take 230V as switch input, others 230V als momentary button, others have to be wired in very exotic ways... No configuration options at all (at least I couldn't find that), very sparce documentation in advance. Somehow frustrating...

Some additional remarks: From "outside", afaik deconz behaves to a large extent similar like a hue bridge (e.g. also allowing Adroid apps lie HUE Essentials to connect), so besides FHEM also other Controller software might be able to integrate it.

Some vendors of the ZigBee stuff I've integrated (or at least tested): Xiaomi (sensors are ok, but keep away from relay stuff), Müller Licht, Ledvance, tradfri, various "chinese no name" (e.g. sold by Lidl and/or Ali express (almost all working!)), Sonoff (We-"something", not satisfied in all cases).

Basically, most ZigBee gateways should be able to interact with Nodes from other vendors, too. The protocoll is very much standardized...

I'd recommend to have a look at zigbee2mqtt and deconz (using a ConBee II, that's also compatible to zigbee2mqtt). I myself use deconz in FHEM and originally started into the ZigBee world with z2m@CC2531 (CC2531 is outdated imo, I personally disliked the update mechanisms for z2m).

Use this syntax instead:

#define SN "GatewayESP8266OTA_v3"
#define SV "1.01"
[...]
sendSketchInfo(SN, SV);

@pikim said in RPi gateway options:

I thought the W5100 must have its own SPI bus.

That seems to be true for AVR at least.
I'd been taking about sharing SPI on node side, e.g. for common use for Radio (nRF24) and MCP4341.

I'm unsure at what level of experience you are with MySensors in general. Assuming you beeing complete noob wanting to start with RS485, I'd highly recommend to just start with a simple serial gw - built using an ordinary Nano and RS485 modules. As soon as this works, you may choose how to adding any other kind of complexity, either on the RS485 side (by usage of CAN transceivers) or be it switching over to STM32, later adding LAN modules...
Doing things step by step most likly will lead to faster progress in the end (imo).

@pikim Don't understand your point. It's even possible to use SPI0 for e.g. digital resistors together with nRF24+. In general, MySensors isn't that special, you just have to adress things at the right point in time, e.g. use preHwInit() to initialize other SPI Hardware on the same interface.

@pikim said in RPi gateway options:

The ATmega324PB would be perfect imo, as it offers 2 SPIs, 2 USARTs and 2 I2Cs. Unfortunately Arduino supports only one of each type - that makes things complicated again.

I'm not sure wheather this assumption is right. Where comes this info from?

I've already worked with STM32, so that wouldn't be a problem. [...] And I'm afraid that the STM32 is not so well supported as the AVR or a SAMD21.

I just have one other's users report wrt. to STM32 in mind, stating he got relatively big binaries for "easy" sketches and a need to get the right versions of libraries and STM32 board definitions. Didn't sound like fun, so I never went for anything other than AVR...
Nevertheless it's possible to get that up and running as well, but for a start I'd highly recommend to use "common ground".

See also the short write up here: https://wiki.fhem.de/wiki/MySensors_Starter_Guide#STM32