Best posts made by rejoe2

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

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?) .

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!

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

You seem to have directly accessed the EEPROM; as you already have found out, there is only a specific area reserved to store from sketch side and some functionality provided to do it in a "save" way. So you will have to split your information on the card ID's and use the "MySensors"-way...

If the Node isn't working, I don't believe you bricked the nRF but the node will not boot or get correct communication info from EEPROM. So just use the MySensors (!) clear EEPROM sketch and reflash the Arduino...

On I_DEBUG: Just set the option in the sketch; the letter is used to identify the type of request at runtime ("payload"). "E" will just erase some basic info afaik, especially NodeID and ParentnodeID.

Hope this makes the picture more clear.

Afaik, heartbeat (and other internal messages) are designed for "internal" use, so the automatics behind that is - without further changes in the internal coding - not meant to be used by "regular" receive function.

Why don't you just use other data types like S_CUSTOM to get the same result?

@Stef9998 said in not understanding Smart Sleep:

@rejoe2
I'm in the process of configuring an OpenHab instance, and the binding should support smart sleep

Don't know about OH's abilities, I "just" did the FHEM implementation of that feature .

That I don't understand. Why should the controller have queued messages when the node is sending the second type (going to sleep). The controller knows the node is awake (cause of first/awake message), so why should it start to queue them? It should just send them, and then when the controller knows, that a node will be asleep (second message) start queueing.

The user or some automatics could create some message to be sent out at any point in time. But sending out any message only makes sense when the controller knows the node is actually listening - these are sparse blinks in time, so most of the time a message will be queued first (or let's call it retained to stick to mqtt conventions).
Then the controller has to wait for a signal from the node side, but as described earlier, this should not be the "awake" message (meaning a sensor can deliver some values and so on), but the "will go to sleep" one (meaning: "I will stop talking now, but continue to listen for 500 ms now").
Hope the fog is clearing now...

@koniu In general this is possible. Both mcu's have to be configured as a gateway, so you may base your code on the serial gw sketch.
BUT: Handling multiple GW's is not supported by all controllers and using 2 mcus with a CH340 USB-serial converter (in case your nano is also equipped with that type) may be tricky to handle in Linux as they seem to be identical for udev etc.
Wrt. controller: E.g. FHEM soports multiple GW's but will mesh all incoming data in one Node and can only use one of them as an adress for active commands like switching relays or set initial values for counters. So at least use different Child ID's for your "S"-es on both mcus

@tomasandersson Did some work wrt. this some time ago, sketches for MySensors 2.0+ are available here: https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency.

Easiest to use may be the "stored id"-Version, based on a concept of leodesigner. This is designed für max. 20 DS18x20.

@Dick Most likely your problems are related to the use of analog out pins for switching on your relay. Maybe your problem is solved by addressing pin 14 as the digital equivalent to A0 (see https://forum.arduino.cc/index.php?topic=147582.0).

In case you have to use different PINs, you could use an array to store info about the used pins, see https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33# as a (more complex) example.

@NeverDie I'm not sure, if I got your problem right:
Do you want to have different values reported on the same ChildID? There are other sensor types doing so, most generic would be the S_CUSTOM, allowing up to 5 different info-channels for the same child. Afaik, there is no logical limitation wrt. data types to use for VAR1 to VAR5, just a limitation in the payload length (around 12 chars).

Just a quick shot, might not be right:
Perhaps this type of hardware is "too fast" in sending in data over serial?
Try adding a short wait() or sleep() in before() to make sure your controller is already up and running when presentation() is gone through.
Or call an additional presentation() from controller side (don't know whether domoticz supports this).

Hello together,

there is no "right" or "wrong" answer to this questions imo. Both concepts have their two sides.

Personally, I prefer to go the multisensor way (and also use RS485, which limits the numbers of sensors to 32 per gateway with standard interface boards). In addition to that I also like the idea to let the arduinos decide (some) things locally or make them configurable to some extend. So things may not become completely out of controll in case there is (temporary) no controller.

Advantages:

• Less parts, especially power adopters/batteries,
• less "optic irritation"
• better use of arduino potential (use of more than 40% of the memory, not sleeping all the time)
• Less RF, means also lower risk of RF conflicts (or best: no RF at all => RS485)
• in case of e.g. failure or power off, I will most likely notice this earlier because of the bigger "footprint"

Disadvantages:

• its (sometimes) hard work to get things working (but also fun and satisfaction )
• higher risk of messing things up because of bad code (I am just a beginner in programming. This is more related to distributed logic as mentioned above; just combining some simple examples isn't rocket science...)
• in case of e.g. failure or power off, a multisensor has the bigger "footprint"

So it's up to you which way to go (or to which extent, to be more precise).

As "setup()" (at least in most cases) requires a working network connection, you may put the "turn off"-code in a different function named "before()" or "preHwInit()" to make sure they are turned off at a very early stage of the nodes reboot.

This wait() can also help to avoid packet losses due to insufficient power supply when using nRF24.

@mfalkvidd said in MySensors USB GW:

@alexsh1 if there is only one tty, linux has only found one of your usb gateways. Unless linux finds the gateways, there will be no way for Domoticz to talk to them.

As basic communication seems not to be an issue (beside the version information that per default only is included in presentation()), especially when rebooting the mc, imo this isn't a problem on the Pi side. It's just the mc booting much faster than the controller...
As there's no USB-Serial converter in the setup @alexsh1 uses, the mc will not be reset when communication is (re-) startet from controller side - imo that's all.
Some explanation, might be of interest for future discussions on that: I had comparable "problems" using a Pro Micro as a GW; this mc also will not be reset when USB communication is reconnected. Most likely also other mc's providing direct USB communication (e.g. STM32F1xx) will show similar behaviour.

@giangired Each etherneted node eventually has to be a gateway, so this concept may not be the best solution.

If you just want do a wired communication, you may have a look at the MySensors@RS485 option. Using real ethernet, you may better use other options, e.g. the firmata project.

Afik, the only option is to use seperate GW's.
There can only be defined one transport per Node. (This has been discussed before wrt to RS485 and nRF24, don't have the link by hand).

@bluezr1 Good progress!
In case you are interested in how to shorten this kind of code and be more flexible in assigning PINs, you may have a look at this post here: https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33# by @korttoma
Just delete the relay part...

@hoggin At least according to my experience, just downgrading the AVR Board Definitions to <=1.6.11 using the Board-Manager within an recent version of the IDE should have done the trick; downgrade of the other libs including mysensors (2.1.1) was not necessary.

In Addition: For the serial Gateways this kind of trouble seems to be solved since version 1.6.18 of the AVR-Board definitions (shipped since several weeks).

Some remarks:
If you plan to go only the esp8266 way, you may have a look at the espeasy project (also for the esp-based sonoff-devices).

BUT: The big advantage of MySensors - especially when using serial gateways - is: You don't have the need for additional infrastructure as LAN or regular WiFi-Network. Additionally, the wifi data is stored on the ESP-chips, so in case you change your WiFi password, you will also have to reflash all ESPs (at least to my understanding).

Then: Using only "real" linux machines as you originally intended by using the zero Ws means also, you will have to take care about regular updates on all these devices to keep them secure. Using arduino devices is different: once the firmware is working, you will only have to make updates when there are significant changes in transmission protocols. At least until now, you can use "old" nRF-nodes programmed with mysensors Version 1.5.4 (or even older) alongside with GW's using the most recent code version.

So also these "old-fashioned" Arduinos have their (big) advantages. Imo changing from Arduino to "modern" devices is not the best idea. My personal preference would be to include old Arduino-based hardware using RS485 (2 wires) over rfm69 (@868MHz) to nrf24. The RS485 and nRF24 modules are pretty cheap, I bought my last ones at around 3.50 to 5 Euro per 10 pieces... (OK, nRF are often fakes, this is why rfm69 might be the better choice, but once the nRF-nodes work, you also don't have to worry about them any more).

Jm2ct.

@dbemowsk The serial API (=communication between controller and GW) doesn't distinguish between different transport technologies used in a specific GW. So it's not important if a GW is using nRF, RS485, RFM69, none or whatever else as a transceiver.

@ben999 You are welcome.
For "indirect" communication you may use the V_VARx-method already mentionned. This requires the controller to have the requested info stored at the right place (eg. FHEM would store V_VAR1 of Child 101 in a reading named "value1101" of the respective device).
Then just use the EnergyMeterPulse-sketch as example how to ask info from nodes side to be send from controller while not sleeping.
That should do the trick.

Just one remark: Having a display and a sleeping node doesn't fit to well together imo

EDIT: To make things more clear: the V_VARx has to be stored in the values of the requesting node, so if the display is attached to node 6, your controller has to provide the values as reading on node 6...

@chaeron
Thx for asking.

Repo-link was mentioned above, @rejoe2 said in Temperature Sensor:

If you are interested: here .

Btw: the sketches have been updated and compile now also with MySensors 2.2.0-beta. But to be honest, I didn't test them with hardware until now. So feedback is appreciated :simple_smile:.

You may have a look at the RCWL-0516, at least some info about that is published here: https://github.com/jdesbonnet/RCWL-0516, nice video about it here.

It even works through walls (so having more of them very close togehter seems not to be a good idea) and already provides a regulator (3.3V), not sure if is supplies enough power to an arduino.
You may need to do some experimenting on the values of caps and resistors needed to get it working according to your needs.

Additional remark: your thread title is very general. Why not change it to "Recommendation for Motion detection (no PIR)?"

@mfalkvidd Your conclusion with the max of 254 nodes to be handled by FHEM seems to be right ! But as I like to combine sensors, most likely this will not be a practical limitation to my personal use cases.

Wrt "better controller": FHEM seems to have other advantages - starting with the small but important point that to some extend I personally understand how to use it . And it is able to handle properly and direct the most of the commercial hw I use (Homematic - afaik there does not exist any comparable solution wrt this hw).

So how about possibilities to split up gw and node reports? Misunderstood from my side? Possible, but hard work? Small change in code?

@ben999 said in MySensors - Get Temperature value from another node through the Gateway:
Thx for reporting about getting this to work as expected!

FHEM seems to be some type of controller software like Openhab and so many others... ?

FHEM is - as mentionned in my signature - also a controller software. It's written in perl (which is very special) and a very flexible solution allowing a broad spectrum of hardware to be integrated, but unfortunately not very famous outside Germany (as most posts in the forum are in german). But questions in english are also answered, see fhem.de for more details, if you're interested.

@mfalkvidd I was reffering to this part of the serial output:

0 MCO:BGN:INIT REPEATER,CP=RNNRA--,VER=2.1.1

Imo, the only thing that is not standard is to also use a comment when presenting the individual temp-sensors:

present(i + DS_First_Child_ID, S_TEMP, charAddr);

FHEM doesn't care about that (just ignores this comment), but maybe other controllers don't like that at all. (I added this as it is a possible feature and may be helpful for others), but @Dick , you could try to delete the last argument.

The power aspect imo is something to look at. One of my nodes had working for ages using 1wire and servo together (standard servo lib).
Additional remark: Instead D2 and D3 as described I'd recommend to connect sensors and servo to different pins. In the future also nRF24 may use interrupts (default: D2) and in case you want to add a counter, this is easier done using interrupt-based coding (wrt. D3)

@sergio-rius You know about the MySenors roadmap? It's open visible to everybody here: https://github.com/mysensors/MySensors/projects. Aint't that the sort of "list" you were thinking of?

Not being part of the dev community, but most likely there are no "hidden side projects", so in case you have additional ideas for the roadmap, feel free to open an issue on github .

But most likely we are far OT by now here.

@joe13 Your naming convention ist a bit confusing.
In general, for sending info to the controller, you can use the "short" send() command in the form they are included in the examples from the Build section.
The additional parts between the points (setDestination() and setSensor()) just change the default values (setDestination usually is "0" for the GW; setSensor() is typically defined in the ...Msg() in each sketches header section (in your example: pcMsg()). V_VAR1 btw seems not to be the right type for this kind of message (Temp).
You may have a look at the "Temperature" sketch: This is a good official example how to use the setSensor() variable dynamically.

Hope this helps to light out the remaining questions, it's quite hard for me to explain all these things. I myself learned about these mechanisms by studiing the examples and doing some (...) tests, but I'm not an educated programmer, so I am not able to lead you to the right keywords for theoretical backgroud.

Today, the "Basic Structure" section contains just a "normal" Arduino structure.
Wouldn't it be useful to also add a slightly extended version mentioning the split of the original Arduino-setup() to begin()->presentation()->setup() when using recent MySenors libs (since 2.1.0)?
This is not very transparent to quite a few users, and yet some of our examples do either not mention "before()" at all or do not make use of the new logical execution time of setup(), even if this would be helpful (!pcReceived in WaterMeter-Sketch, getControllerConfig(), for metric in Temperature, just to mention some examples) .
Also the text order of setup() still beeing above presentation() in at least some examples may be technically irrelevant but nevertheless misleading to some extend.

@ehome said in Looking for reliable PIR human detection sensors:

@rejoe2 Have you already made some experience or used these microwave sensors as motion sensor?

I use several of them on a couple of RS485 MySensors nodes and also know some others in the FHEM forum using them with ESPEasy. So as far as I know the most common problems with the RCWL's are power-related (ESP8266 is a 3.3V-device).

As I have some problems with my RS485 setup the following is somehow preliminary (seems the 12V to 5V conversion is root cause; this also affects the RCWL's):
The ones I use myself are in my cellar and in the garage (two rooms in the later). In the cellar, detection is indirect (PIR on same wall as entrance door): Works very well, but also detects the opening of the door from corridor towards a second cellar room - there's a small hole in the wall between these two rooms near the PIR's position... So motion is also detected when just passing the cellar.
In the bigger garage room, it works perfectly - when there's enough power for the entire node - the converter on the pro mini seems not to supply enough power to get the RS485 chip working sufficiently in all situations. There it's placed on a side wall - no detection, when passing outside, but opening the front door is detected pretty reliable, in some cases, one has to do one step into the garage, detection angel is 80+ degrees .
The third RCWL I only recently installed, so there's not too much enough experience to talk about, the others are up and running for months now. But at least the radio fields of both RCWL's in the neighbouring rooms in the garage seem to not influence one another I had some doubts on that point as I first tried to use 3 of the RCWL's on the cellar node to monitor the two cellar rooms and the corridor; that didn't work - as I now think due to powering issues.

I did some experiments wrt the resistor placement, but by now, all are just without one (but I can also state: one can see a difference)

So keep us updated once the parts you ordered are up and running!

@soloam OK, so in the end this seems to be a problem related to that particular controller software. Imo it would be better to address this issue by enhancing the controller software towards a more constant handling of added infos from user side like renaming devices rather than using the limited space on the mcu to store info not needed by other controllers.

@joe13 As you are doing the data transfer through the controller: How did you transfer the info from Node A, V_VAR1@Child X to Node B, V_VAR1@Child Y? If you are issuing request(), you are asking the controller to send the later info.
How to manage that is not a MySensors question - it's controller specific. @FHEM, one would use typically a "notify"-function to copy incoming info from one node to the other.

@mfalkvidd
Your understanding of my suggestion seems to be 100% correct. I will add some additional comments and some (too complicated but working examples) as links at the github page.

@skywatch said in Solar/battery powering:

@zboblamont said in Solar/battery powering:

@rejoe2 Anti-freeze.

But then the hot water would not be suitable to shower/cleaning/pool etc and you then have to go to a heat exchange tank, somewhere to put it and insulate it and pipe to it. I am sure is can be done, but the fact that it is not 'standard' hints at it being costlly or impractical or both.

In fact, imo it's highly recommended to use a seperate circle for the "transport medium" (typically: antifreeze liquid)! Otherwise you will at some point in time get problems with corrosion or deposited dirt particles if media would be continuously renewed. Dependent on the needed amounts of (potable) warm water, it might even be a good idea to have three circles (medium for panel, heating water, potable water). But tanks, heat exchangers and so on (including steering electronics ) are (relatively inexpensive) standard components - at least here in Germany. So imo technical complexity isn't a thing to worry about too much. But as already mentionned: I really doubt, if you will have a financial benefit out of such an installation, if you have to built it from scratch nowerdays. Additionally: have a close look, how big the need for hot water really is - in most cases, e.g. 5m² panel size for a family of 4 persons should be enough for hot water supply in middle Europe (+300l tank volume). As soon as heating is involved, you'll need much higher tank volumes - with no benefit in summer, but not sufficient capacity on roof top or tank volume in winter times?

@rejoe2 Agreed! - But it's not OT as you could mysensors the hell out of such an installation!

Indeed, buiding one's own MySensors-based controller for such a hybrid heating ecosystem would be right on topic - but not in this thread here...
Fyi:

• One of my very first things to get done with MySensors had been around my (gas based) central heating system;
• we have some tubes installed that would allow medium transport from roof to cellar. But to be honest, atm. I'm not willing to invest in tanks etc.; it's just not cost efficient, even if I would do a lot of the installation work myself....

@sergio-rius Sorry for the somehow misleading referer: Meant was : "Me not beeing ..."

@ostoja Please add your code. Most likely you just transfered the DS18x20-Code into the relay sketch including the sleep() at the end of the loop().
If you did it that way: This had been discussed here several times, you have to change the code into a so-called non-bocking loop().

@hypnosiss Hi there, glad to hear someone is developing code for venetian blind covers .
Just some thoughts on this:
Despite using some kind of custom field might be ok or having a commonly used seperate variable might be fine as well, I personally would tend to just use a second set of the S_COVER-variables under a seperate child ID.
Not sure, how other home automation systems deal with that, but this seems to be some kind of standard for actors supporting a venetian blind mode. E. g. newer Z-Wave devices like Fibaro FGR-223 or Tasmota (starting with 10.0.0.4?) also just present a secon "blind" to control tilt position.

@Mohammed-Zaman This seems to be possible, you may find more info wrt your topic using "node to node communication" as a keyword for searching the forum.
This might be a good starting point: https://forum.mysensors.org/topic/6386/almost-controller-less-mysensors-switch-light-network/8#

@bladeback This has been asked before several times, for further investigation you might look for "node to node communication".
As a starting point, you may use the following thread starting with this posting: https://forum.mysensors.org/post/84724

@qobouky If I got you right, you question whether it is possible to receive the signals sent from your nRF24-Nodes via the wireless transceiver of an ESP8266.
The short answer is no.
Both may use 2.4GHz as a physical transport layer, but the encondeing/decoding of the information is done completely different. You may compare that to two humans speaking, but one chinese and the other english - they may hear the other one producing sound, but will not be able to understand the message.

@jonathan-pucel Have a look at the code in this post.

Despite beening not familiar with any of the mentionned controllers, having multiple serial GW's seems not to be a big issue imo.
Atm, I'm running 7 USB-connected IO devices (4 of them for MySensors) on FHEM without trouble. The only point to keep in mind is how to address all these devices and not to mess things up. To achieve this, I just address all of the GW's with their "/dev/serial/by-id/<identifier>" path.
So when buying Arduinos, don't use more than one with CHG340 USB-serial converters (often to be found on the cheap chinese Nano clones) but chips that can be identified by an individual serial number (may need some more work in case of e.g. CP2102 chips that come by default without serial number but can easily be programmed).

Can you please give more background info?
I don't think it's a development issue but either related to domoticz or to the code on your node. Would you mind posting your sketch?

@Pavel-Polititsky
To me this looks like you mixed between-node communication (RS485) with debug output (and maybe also serial output of the gw).
The corresponding serial interface for RS485 should be dedicated to RS485 exclusively.

Imo the "right choice" also depends a little on your controller software. As a first try, I'd go for S_COVER; this allows direction info and percentages. You may combine it with a S_DOOR type for direct indication of open/closed (in case of pure S_COVER derive info from percentage values).

Have a look at https://www.mysensors.org/download/serial_api_20 on what MySensors offers and also a look how your controller handles the different types.

Question: First all worked well, until you added the code for the DHT?
IMO, the

// Sleep for a while to save energy
  wait(UPDATE_INTERVAL);

part blocks the entire code for most of the time. You should instead use a non-blocking loop structure using millis(). See the https://www.mysensors.org/build/pulse_power example (follow the path, when "#define SLEEP_MODE true" is used).

@GieBek

6137 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:

Imo this indicates your node doesn't have a NodeID yet. When using RS485 you have to assign the ID's manually in the sketch, auto doesn't work... (e.g. #define MY_NODE_ID 123)

I personally found a lot of useful information about nRF24-usage here: http://arduinoinfo.mywikis.net/wiki/Nrf24L01-2.4GHz-HowTo
(Moved from arduinowiki).

There's a lot of info, the only thing that's missing is how to identify counterfeid chips.

@michlb1982 Congratulations also from my side !

One additional remark: In case you want to use more relays and buttons, you may hav a closer look to the use of array functions. Good, but rather complex example: https://forum.mysensors.org/post/51488

@bereska said in Water Meter Pulse Sensor:

Is it possible to get any help on this page or not?

Crying out loud most likely will not help...
Seems your setup is a little special, so just some assumptions from one using a serial GW and not MyS-MQTT:
Your controller is asked for sending an initial value, but has none yet. So no answer is sent out. Triggering the counter on Node side could help to send one (after waiting time has passed). Then have a look at your controller, if there's a value available. If, you might set the correct value, restart your node afterwards and see, if everything now works as expected?

@1kohm Perhaps you have a look at this sketch to get a good example on how to "loop" alsmost eveything:
https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33

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.

@bereska said in Water Meter Pulse Sensor:

32319 TSF:MSG:SEND,6-6-0-0,s=1,c=2,t=24,pt=0,l=0,sg=0,ft=0,st=OK:

Logparser states: there was nothing counted (empty payload). So make sure, there really was counted anything.
(I didn't check your sketch, just assuming, it's the default one and everything is wired correctly; if that's the case, you should be able to see a different payload than nothing or "0", that your controller might treat as non existent).

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

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

@ibibiuooui said in Water Meter Pulse Sensor:

!TSM:INIT:TSP FAIL

See https://www.mysensors.org/build/parser: There's a problem in the initialisation of your transceiver (whatever it may be). So first check wiring, see https://forum.mysensors.org/topic/666/read-this-first-it-could-save-you-a-lot-of-time for further details. If that doesn't help, imo you should open up a seperate thread.

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

@LastSamurai
According to my personal experience I would answer with a clear yes! The +PA+LNA-Version gets better receiving results and generates a stronger signal when sending. So -apart form adding a capacitor- changing the module on the GW imo is also an action to recommend to improve the overall results. You may in addition think about shielding both decoder chips (not the antennas).

@hermann-kaiser said in SmartSleep and FHEM - does it work?:

There is a new maintainer for the module in fhem. He implemented a lot of new stuff and also the smartsleep feature. For example nodes are now showing if they are sleeping.
Also messages to the nose are delayed till it wakes up the next time.

I'm not exactly "a new maintainer", just an additional one .
But imo MySensors@FHEM indeed has made "some progress" the last months including OTA update ability (code was mainly contributed by someone else).
So expect some more things to come soon. Next will be the attrTemplate feature included in FHEM's setExtensions. This will help to easily improve the "look" of MySensors Nodes in FHEMWEB. If you're interested in contributing, just give me a hint here or in the FHEM-forum (the later is more related to FHEM, so I'd prefer the FHEM forum; you may also post in english there - especially in the MySensors subforum).

@monte said in Where did everyone go?:

@NeverDie I am just paranoid about relying on a cloud for everything.

Imo it's not only the technicals problems wrt. to connection cut off and so on, but also relying on cloud services raises a lot of security issues, see e.g. https://www.youtube.com/watch?v=urnNfS6tWAY (unfortunately in german) wrt. to all that stuff working with sume "Tuya"-based "App". "Military grade security" for cloud bases solutions?!? Complete illusion, at least with these offers from far east also distributed by some discounters here in Germany...

@NeverDie said in Where did everyone go?:

Even today, most weather stations and temperature sensors [...]

There's some clever solutions in the world to get the data out of these locally, e.g. OpenMQTTGateway for a lot of BT stuff and some 433MHz gadgets. I personally use FHEM as central Home Automation system, also offering a vast variety of solutions for 433MHz and 868MHz proprietary stuff out there (see keywords CUL and SignalDUINO in the command reference without the need to use any cloud service (including somfy, water meter signals, ...). Might be tricky in detail, but there's quite some folks out there using FHEM for the single purpose to bridge some special RF stuff to the MQTT world, btw..

As my own activities wrt. to MySensors, the stuff I soldered several years ago just works (actually running on some older beta version). So no need to aks tricky questions atm..

Not sure, if I got your ideas right. Imo, (de-) powering the AMX485 may just be fine within the loop(). Some remarks wrt this (afaik):

• the MyMessage-definitions are just definitions to prepare sending command structures, but there's no direct send command issued. So there's no need to (de-)power any transceiver at this point in time
• the DE-PIN is not related to powering the transceiver - it just indicates the direction of communication (high, when receiving, low while sending, maybe pulled to low from transceiver side when receiving starts (RE) to trigger an interrupt at PIN2)
• when switching transceiver on manually in loop(), you may need a short wait() to make sure, transceiver is correctly initialised (didn't test anything like that bevore).

Hello Simon,

afaik it is the intention behind the option to define a MY_TRANSPORT_WAIT_READY_MS statement, see hek's post here: https://forum.mysensors.org/post/54403

Basically, you seem to search for a "multi-contact-multi-relay" solution. This for sure is possible with MySensors, but still the question remains: Why MySensors at all? For that kind of task, no controller is needed, to me this seems to be "just a simple arduino sketch" running on a single MCU.

Independend if you want to go the MySensors route, imo you will have to go through a fast learning curve. Good starting point may be https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33 - but this is with monostable buttons and not bistable contacts. So first steps could be to understand, how this sketch works and can be extended to more buttons/relays (you may need port extenders or a different MCU to add more PINs), then to adopt it to bistable contacts, and last switch additional relays for the "indicator LEDs".

Additional remark: If you finally want to use additional controller software and "need" additional communication between multiple MCU's (for other tasks), have a look at RS485 transport layer (or PJON (in development?)).

@qobouky
Interesting approach, I have some ideas to also go this route (just as a central scene controller), but didn't find the time yet to get that done (and some other challanging tasks with higher priority).

So some of my findings wrt. using displays with MySensors:
Sharing SPI is possible, see e.g. the Dollhouse TV example. I also did some poc work wrt. that, code is here with two digital SPI resistors parallel to the nRF - works, just requires 2 additional pins for CS and some initialisation in before().

But as especially using graphics modes might need more power and memory than a ATMega328 can provide, the scene controler uses an ATMega 2650.
If you want to miniaturize things, you may have a look at other mcus like STM32F103 or NRF52. One of my next projects will most likely "require" to use the STM32 (also MySensors, but - most likely at least in the first version - not with a display).

@Daniel-Ruiz je parle aussi un peu de francais, mais comme ce n'est pas gentile aux autres, je continue en anglais:
This is not a a good idea to "solve" the problem like this.

What is necessary is a global variable. This has to be introduced in the header of the c file (before the before() part). But as in the header no calculation is allowed, we have to do this calculation somwhere else (proposal was in the before() section. It is sufficient, to do this once, but it would also be possible to do that in loop(). If you do not want to calculate at all, you may just delete everything with "conversionTime" and do a sleep() with 750ms like that: sleep(750); this is absolutely necessary to get proper results from the DS18x20!
Further remark: If you want to go further steps with MySensors, you should try to understand the meanings of global variables, data-types, initialisation-functions like before(), presentation() and setup() and the loop().

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

Why don't you just use an existing message type to send the time to the controller?

Imo the real challenge would start the moment the GW handles the message over to the controller:

• has the controller sw the necessary rights to change system time (in my case: no...)
• how to deal with conflicting info from different sources?

Imo, it's already possible for the rare use case there might be left over (but as explained needs some manual configuration). Especially when using a Pi: add a RTC and make some manual updates on that every now and then (if necessary).

Just my2ct.

@moskovskiy82 You may at least have to chang this:

MyMessage lightMsg2(2, V_STATUS);
MyMessage dimmerMsg3(3, V_PERCENTAGE); //ADDED
MyMessage lightMsg2(3, V_STATUS); //ADDED

The second imo should be lightMsg3...

I completely agree with @BulldogLowell : Better use arrays for nodes like yours. Good example: https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33#

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

Did you already follow the procedures described here: https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help

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

Just some guesses:
The PIN assignment for arduino nano is due to the use of altsoftserial lib.
Most likely you may rather use hardware serial on ESP8266. See http://esp8266.github.io/Arduino/versions/2.3.0/doc/reference.html for the relevant PINs on the ESP (most likely serial0 is the better choice).
Connect DE-RE (linked together) to any interrupt-capable PIN and adopt sketch accordingly.

Btw: What is your motivation to build a wired network and then connect the whole thing wirelessly to your controller? (I personally try to get rid of all RF transmissions, so this is why I use RS485 as preferred transport layer and connect the whole thing via USB...)

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

Hi all,

my serial GW recently stops transfering messages to the controller (FHEM) after several hours of operation (or even days). As soon as a "connect"-command on FHEM is issued, new messages from my nodes are processed again, but after a longer period, it will fail again. The "connect" seems to cause a complete reboot of the GW, despite there is no change of date wrt to the initial binding in the filesystem in linux (date in ls -l /dev/serial remains unchanged). Rebooting all or individual nodes does not have any effect.

Does anyone else have similar observations?

Some background information:

• All nodes+GW use MySensors 2.2.0-beta, programmed via Arduino-IDE@linux

• GW-Arduino is FTDI-based (seems to be no fake - I changed the USB identifiers -, Test-PIN is connected to ground)

• Everything was fine for weeks using just one of my nodes (Node_1) and the respective GW

• Problems started as soon as I added two new nodes some days ago.

• Wiring:
  -- All nodes are wired on just one line, no stubs (had one first to Node_2, but changed this already)
  -- cable (CAT7) starts at GW, 15-20m (just one pair for data) to Node_2, 6-7m to Node_1 (+12V for power supply, provided at Node_1), 8-9m to Node_3 (again: data+12V)
  -- beside the screwed connections to the RS485-modules, there exist one or two additional connections via small WAGO clamps (4 in total until now, at least one in between every node)
  -- all nodes+GW have the "long" modules (chinese source, ebay), all resistors still in place.

-Nodes (mentioned only the sending childIDs):
-- Node_1: 7 DS18B20, 1 Counter = 10 infos to be sent every 5 minutes. (some of them in some cases a bit more often)
-- Node_2: 12 DS18B20, 1 Counter = 15 infos to be sent every 5 minutes (again additional things like 3x motion and a switch when relevant)
-- NODE_3: BME280 = 3-4 infos every minute

• Power:
  -- GW is powered by an active USB hub, that also powers 4 other Arduino-based devices
  -- all other nodes are powered by the mentioned 12V-line using just internal regulator (Node_3) + an additional adjustable step-down-module (ok for up to 36V DC in).

• Some delay in sending is already implemented in Node_2, this seems to help a bit (I originally was convinced to have powering issues with this node, so I applied the known workaround from nRF-tranceivers. But in fact, it seems to work properly and infos are lost on GW side).

• All Nodes have #define MY_TRANSPORT_WAIT_READY_MS xxx, xxx beeing different on each node (3, 15, 30 seconds)

Possible root causes and next steps:

• Change GW-HW (Arduino+Transceiver module), maybe I damaged the later when making test while adding the new nodes (really doubt this now wrt the longer times of correct operation, but we will see).
• Replace the adjustable power modules by some LMS1117 modules (should provide more power), esp. to Node_2 , where I can see that one of the 3 buses for DS18B20 (5 Sensors) is also not working reliably
• Try to reduce the amount of data send by the nodes by adding some delay?
• your ideas...

Will keep you updated in any case!

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

So one more intermediate update:

• Desoldered all resistors (R5 to R7 on the LC-tech rs485-modules) on nodes 1&2 (was not much more work, so also the 20k's, just to be sure...) and added pullup/pulldown 1k's on Node_2 (that is somewhere in a middle position wrt. other planed nodes and near the 12V power source) as proposed.
• Didn't change anything on the code yet.

Until now, everything looks fine, I get updated values as expected from all of the three.

I'll keep you updated, but (I hope so) this will take some time to have longer-term-results.

As I could nail down some more parts (but still do not have a reliably network), also a short update from my side:

• Node_1 (Multi DS18B20 (*12@three pins) + other things) is the biggest troublemaker. It just pulled the Voltage between a+b to +2.8V after some time. There is some hours of delay between the last messages and the node stopping also the pir functionality (no wdt code implemented).
• Node_2 (also Multi DS18B20 (*5@three pins) and other stuff) also stopps communication after some time (it originally worked, this may be related to whatever change happened in between). But this one doesn't kill the entire bus communication and seems to work internally (switches relay on in case a rise of temperature is detected). This also holds my pullpup+pulldown-resistors for RS485.

Yesterday I switched over Node_1 to use HW_SERIAL, as I also suspected altsoftserial to be part of the root causes. At first sight this seems to improve things a lot.
Next, I will review Node_2 for the use of HW_SERIAL.

What I have in mind (may not be correct):

• HW_SERIAL uses less memory. So this may prevent the node to have some kind of overflow
• there may be an conflict in internal timers, as 1wire may also need a timer (I use amongst others also PIN10 for 1wire).

Yes, you will need a controller.
(This is not 100% true, but doing that requires deep insight how things wort, as far as I understood).
The controller just has to have a connection to the GW - see different GW types on the MySensors page. So for you easiest way would be to convert your mega to an EthernetGateway. Which one to choose may be not easy, but most of them will not need high end hardware (seems many can run on a raspberry or similar).

@newzwaver your code is pretty hard to read due to not beeing entirely formatted as code.
Nevertheless there seems not to exist any loop() section and the node is put to sleep after having received anything for a certain periode of time.
This may work in most cases, but imo is not a "lucky code design".

Imo better aproach:
Use the https://www.arduino.cc/en/tutorial/BlinkWithoutDelay - principle. Additionally a wait() is used instead of sleep() for the time to fulfill measurements (DS18B20 in my case).
If you need a working implementation of the blink-without-delay function within MySensors, see the https://www.mysensors.org/build/pulse_power example.
At least three of my nodes (combining temperature and relays) work pretty well like that.

@bluezr1 Great to hear about you having first positive results.

Nevertheless, imo the sketch you posted is designed against some basic principles.

First: all main functions should be placed in the loop() section (not present in this sketch). The posted sketch does all the measurements within an exceptional routine called receive(). This should be reserved for all functionality that really is related to receive any info from controller side - obviously doing measurements does not belong to that category.

I also started as complete noob to coding around 30 months ago and just followed the examples (mostly from Build section), so be assured: you will also learn how to do this just by following these examples and ask yourself why things are solved the way they are.

If you need a good example of a combined sketch, have a look at the atmospheric pressure one (or the DHT (humidity?) sketch you have used here): They already have two children... From the BME180-Preassure you may follow the route to the BME280 examples available in the forum here or in my repo (#98, RS485).

Btw: In the header section of your sketch there are also two defines left not necessary (just as a info, this does not cause any trouble for the moment).

@bluezr1 Yes, millis() is the right thing to look for (or the simpleTimer2-lib, that internally does the same things). But keep in mind: sleep() and millis() don't fit well together, as after every sleep() millis() will be reset... Use wait() instead of sleep() in case you need short periods eg. between initialising and completion of measurements.