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

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.

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

As everything still seems to work as expected some futher remarks on my findings/hypothesis and todays setup:

General remark: As a lot of things have changed over time and some of my tests turned out to be contraproductive, it's hard to sort out THE root cause now. But as others had some issues with colliding messages too, I'd bet on that and really appreciate if the patch #1142 would find it's way to everyones codebase (@seeers seems to have some issues at github, can one of the mods help him out of that, please?) :grinning:.

Back to my setup:

• Nodes are powered now through a central 5V DC supply, only 3.3V conversion remains locally, GW through USB
• GND of central 5V is not connected to GW GND (in case of trouble, I'd add a "resistored" connection)
• All nodes use Hardware-Serial, Baudrate is @19200
• No debugging messages on nodes activated (if someone wants/needs it: swap debugging output to altsoftserial...)
• Transceiver used: MCP2551, most of them on modded TJA1050-Boards (don't forget to dissolder the R120) => no DE-Pins necessary
• Gateway is a Pro Micro
• Termination resistors: 2kOhm at the last node in line (CANhi->5V and CANlo->GND), 120Ohm (A-B) only at last node and GW

Remarks:

• My long-time GW was a regular MAX485/MAX487-Nano using AltSoftSerial. IMO this over time had been one of the most reliable components in my setup. Conclusion: Most likely this lib is NOT to blame for any trouble I ran into.
• Nevertheless hanging nodes with regular RS485 trasceivers caused problems to some extend. So I really like the CAN logic to switch the transceiver off when it's MC seems not to work properly to avoid infection of communication from other nodes. What I didn't test yet: Using CAN transceivers together with altSoftSerial. So expect some additional info on that later, as this might be helpful for debugging over USB as on any other node
• To some extend all of the transceivers seem to be able even to transmitt in case A-B voltage level is above the "critical value" - depends a little on the strength of the power source. So I'd see this just as some type of "most likely" indicator of a bus problem now.

Hope someone might find that summary helpful and once again:

Thanks a lot to all those people here and at FHEM-forum trying to help me out of that never ending mys(t)ery! :grin: :clap:

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

@ben999 I also had a hard time to sort things out wrt. to node-to-node communication. But in the end, its simple:
You just have to use appropriate send()- and recieve() commands in the nodes. Example for the temperature part, using the node numbers from above:

• For the one providing the needed info (node 5): This one is measuring temp and sends this to node 6: In the code for this node use additionally to the "normal" send() the above code and replace "MY_SISTER_NODE_ID" with 6 and "CHILD_ID_SISTER_TEMP" let's say with 101 (or use appropriate #define's).
• In the receive() part of Node 6 you have to sort things by using the correspondant Child ID as follows:

if (message.sensor == 101) {...

I personally prefer using "speaking names" like CHILD_ID_SISTER_TEMP and define them in the header, that's what's behind the first send() code-snipplet, but that's just a question of style.

@ben999 said in 💬 Temperature Sensor:

And a "dead" sensor looses its bus address (next sensor on the chain takes its address and so on)

That's not exactly right. Each of the 1-wire devices uses a hardcoded, unique address that can not be changed.
So if you use the standard sketch with multiple DS18B20, in case of detached or replaced sensors you may get reported the measured temperatures comming from the same physical DS18B20 device under a different ChildID (after node reboot). To avoid effects like that, one has to take additional measures as described here . In short:

• Use an array with the physical ID's to address them
• Store a hash-array (done automatically) to identify "known" physical ID's that have once been attached to the bus as well as the ChildID used for MySensors.

You are using the same ChildID's for relays and tripped/door states. Imo this is messing things up, so e.g. use 11+12 for tripped values.
Remark: If you are looking for a good example on using arrays for that kind of tasks, see korttomas work here: https://forum.mysensors.org/post/51488

@monte said in Where did everyone go?:

It feels like people come to mysensors, make relay node, temperature sensor

If one just wants to have a temperature (or humidity) sensor or a relay, buying ZigBee or BT or ESP826x-based stuff is cheap and easy, no need to fiddle around with voltage regulators, fake nRF24L+, capacitor sizes and so on. So most people just beeing interested in quick solutions will not even care about these simple sensors.

and then go forward for more complex solutions to never come back.

Imo, MySensors still is a very good solution if you have the need for more complex or "clever" solutions. Choice is not to big, if you are looking for solutions with wired or LoRa nodes, and scripting more complex "rules" for Tasmota or ESPEasy seems not to be very common to build somehow autonomous subsystems.
Btw.: node2node communication in MySensors is not well explained as well. So also in the MySensors ecosystem most users are used to rely on some sort of central system to do logics as soon as more than one node is involved.

@joe13 The request() call in your loop() is no longer neccessary. Receiving what is sent from another node is handled without that...

You may use node-to-node communication to send the raw data from the BME-node to any other node for further calculation. Most likely best would be to use own ID's after calulation. But if this really is a problem, it's probably better to use directly a different mc (like STM32F103) for the node itself, the node-to-node-way makes things much more complex.

Would you mind providing more info about the calculations problem you mentionned? My own BME280-node is just equipped with an ordinary pro mini...

@alowhum AFAIK, now the order of execution is preHwInit(), before(), presentation() and setup(), then loop().
As you may call the presentation function to be redone from controller side you should decide whether this is desired or not; depends on your needs imo.

Personally, I prefer having all kind of controller-independent initialisation in before() (especially turning relays off/desired state and so on; this allows also to use additional SPI stuff on hardware SPI PINs), put all controller-communication stuff in presentation() and the other things in setup(). For e.g. asking acutal values of counters setup() might be a good choice, as one typically want to do that only once after node has started.