@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

I've no deep knowledge in these things, but imo the proposal from @tmandel leads in the right direction. Just looping once more (and perhaps having the info that the smartSleep-command has been skipped to avoid unnecessary additional measuring and so on) imo is the cleanest solution to this kind of trouble.

This reminds me on a discussion some time ago which lead to this feature request: https://github.com/mysensors/MySensors/pull/1271
Perhaps you might check out if that would help.

tmandel123 created this issue in mysensors/MySensors

open smartSleep revocation feature #1271

@dzjr said in Best choise for a controller:

I also have FHEM running on a Virtual machine, and to be honest it is not what I am looking for, among other things FHEM does not see the sensor names in the presentation, so this will all have to be set manually, and further I saw that you have to set a lot by hand.

There's an option to derive the reading names from presentation info ("get <name> ReadingsFromComment"), but most likely you will not be satisfied with the result. But for sure, FHEM isn't an easy "mouse-based" system to understand and customize. On the other side it offers any option to do whatever you like within your system.
But anyhow: Thanks for having a look!

@robert Use an array to address all available PINs. As a reference (more complicated, as there are buttons used, too), see @korttoma's example here: https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33.

@monte
OK, so let's concluse: FHEM and HA seem to have at about the same functionality - FHEM amongst others also supports KNX.
It's up to the TE (and whoever may read this in the future) to decide what to prefer - I'll stick to FHEM which I'm now pretty familiar with...

@monte said in Best choise for a controller:

@rejoe2 but is there anything that FHEM supports and HA doesn't?

As I'm not familiar with HA, it's rather hard to give a valid answer to this question. As already mentionned, FHEM is strong in hardware integration, so eg. SOMFY shutters might be an example. In general, FHEM gives the option to run a cloudfree HA system, so the need for external (especially google) software to steer some thermostats rather sounds ridiculous to me - FHEM especially is able to control Z-Wave, EnOcean, MAX and HomeMatic (not "-IP") hardware with just an USB dongle for each of these wireless protocolls; my ZigBee installation just uses some piece of software running on the same server hardware and also an USB dongle.

Also FHEM provides some modules for "easy" configuration of typical HA tasks like shutters control (taking into account a lot of stuff like sunrise/sunset, internal/external temperatures, shading needs, individual's presence...) or heating control. Don't know what HA provides in that direction, though.

Also keep in mind ongoing development in contrary to others (over 70 releases on github this year alone). For example google pulled off "works with nest" API, so many users can't use their thermostats with 3rd party software, but one of HA users made a simple dirty hack which makes it possible to integrate your nest thermostat for now, until google will release their new API for users.

FHEM is also under ongoing development, but follows a different release strategy, it's more like a perpetual beta, so updates can not be counted in "releases". If you install the current debian package with release 5.9 and do an update (from within FHEM), you will get around 2.000 commits applied since the release of 5.9 and still be on feature level 5.9. Additionally to mentionned that: the most of the commits not affecting the core part, which is rather stable.
If you opt for the docker version, you will get an up-to date system just from the first second.

Also HA is written in python which makes it pretty easy to fix any issues or add new features.

Python might be more common than Perl these days, but wrt. to that point there's no further significant difference between the two.

Wrt. to bugfixing and reaction to changes "to the outer world" also an example: When yahoo closed down it's weather service (afaik, they didn't prewarn), it took around 4 weeks until there was a different solution provided - without need to do a lot of changes for those users who used the data within their FHEM installations - they had e.g. just to get a key from darksky and change the data source (but internally the code structure had been rebased to be much more flexible for the future).

@dzjr said in Best choise for a controller:

@rejoe2 I had never looked at FHEM myself, I will certainly do so.

As a server, I also received a tip to use an Intel nuc instead of a Pi.

Have a look at Linux compability first when looking for Intel NUC. My HA system runs on a ThinClient platform from hp. Consumes slightly more than a Pi or newer NUC, but only costs around the same as a new Pi.

Wrt. to what @monte said about Home Assistant: Comparing is not really easy, as one can focus on different things, but most likely FHEM might stand the test, especially if you focus on hardware integration and automation (but to be honest: Perl on which FHEM is based is "special" and seems to be no longer "a la mode").
If you are able to read German, you can find some infos on FHEM compared to OpenHAB and IOBroker here - there's also some few remarks from users with HASS experience (most of them highlight the shiny UI of HASS, and there are also some FHEM users going for FHEM for automation tasks and hardware interfacing and HASS as UI).

@dzjr You may have a look at FHEM. At least all of your present hardware will be supported, and it's really a stable base that might run on any rasberry base (despite imo that's not a good choice for any HA solution, but that's different story).

The same ChildID most likely isn't the cause for the missed relay commands, but the "wait" instructions. IMO the code should be changed to a "non blocking loop". Search the web for that keywords or have al look at https://www.mysensors.org/build/pulse_water as an example within the MySensors framework.

@sebex said in Advise - Building air quality sensors/network:

Regarding the 1 gateway, you mean stay away from home automation at first?

Imo, MySensors without HA Controller doesn't make sense or even will not work (without additional tricks). But to get familiar with a specific piece of hardware (e.g. a sensor type like the DS18B20), it's much easier to use the standard arduino sketch examples included in virtually every "library" without additional MySensors stuff first and add that as a second step (or first try if it's working on the PIN you plan, (e.g. PINs able for direct interrupt use are limited and so on).
So you also know, the hardware is working - that unfortunately can also happen...