Posts made by rejoe2

@speechsupply You may be right - pages like the arduinoinfo site are never perfect. But it's a wiki and it seems not to be limited to nRF but also contains some other arduino related stuff beside the official arduino.cc site. So feel free to add further info (after the necessary validation) to that wiki .
Then there's the troubleshooting and debug guide also containing a lot of standard issues: https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help

Imo, there's no need to open up another channel, it's better to enhance the existing ones (and leaving out exotic stuff not properly tested).

Just my2ct.

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.

It should also work on a 3.3V pro mini and as is works for some time at least, there seems not to be a general problem with the sketch.

Some times, you might have buffer overflows in case you get really a lot of data from your network, so increading buffer size on the gw could help (no own experience, standard may be something like 20 messages).

But as I don't have much experience on usage of PI GPIO (I preffer using Mysensors Nodes when GPIO's are needed), I may not be able to help you any further. As a general remark, drawing power from a PI is very often "the root of all evil", so I'd recommend to avoid that whenever possible. But that's personal opinion, not proofed knowledge.

@skywatch I'd first have a look at your USB-Serial converter. Enough power @3.3V? FTDI with tesp-pin not connected to GND?

When using nRF24, imo there's no need for a level converter (beside having a stable 3.3V source to power the nRF), so using a normal Nano should'n be an issue.

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.

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

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

@tbowmo Thx for clarification.
As I only use serial GW's, I didn't notice the difference until now.

@Tubes110
Using a Mega should not be a big issue.

Wrt. to using the MySensors framework without Controller you might look for "node to node communication" in the forum.
A good starting point imo (starting with this posting): https://forum.mysensors.org/post/84724

You have to configure all nodes with

#define MY_TRANSPORT_WAIT_READY_MS 100

as if the controller is not present, the nodes won't enter loop() (100 may be changed).

Would be keen to see your final code; I'd like to bridge ebus communication to MySensors , so your code could help to some extend.

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

Additionally, you may have a look at this WIP: https://forum.mysensors.org/topic/6911/halo-esp32-multi-transport-gw-bridge-for-mysensors

@ruric For usage of interrupts see the Pulse-Meter (Water/Engergy) examples in Mysensors. As your sensor is not sleeping and has no longer blocking phases, usage of interrupt functionality for door or motion is not necessary.

Combined Temp/Humidity: BME280 or SI7021, Temp alone: DS18B20.

Seems already to be quite good, congratiulations!

Beside the DHT-topic: Use a different PIN as 3 as long as possible - reserving an interrupt-option, e.g. for adding a counter imo is always a good idea .

Besides that you may use a debouncing method like bounce2.h for the door and motion PIN's to avoid false triggers.

Are you sure, the sending part of your hardware is working?
In the past I successfully used a comparable code to hard-shovel's proposal (although with a different IRlib).

As you mentioned the "code" seem to be ok in decimal writing, a hardware defect imho is the most likely cause of your headaches.

@koniu said in another sensors connection via usb ?:

@rejoe2 Thanks, it works only with different USB-serial converters - for the same mix children

Sorry, but I don't get your point.
It also works using two CHG340-Nanos, but eg. in FHEM you best would distinguish them using the output of ls -l /dev/serial/by-path

And also when using two different converters it would in any case make much sense to use different ChildID's to avoid mixing up the data from both Nodes.

@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

It's pretty easy to send back the actual state of the relay.

But imho there are several options to improve the behaviour of the whole thing:

• if it's more secure to start the whole thing with the relay switched off instead of reading value from EEPROM. Then ask the controller about the desired state and keep it off until message arrives or button is pressed?
• keep track of the actual state of your relay within the loop(). By now, the switching logic of the button/switch seems to be weired. Does this work as expected?
• if it's a security function: let the node decide whether the relay should be switched off, dependend on the meassured value and the state of the relay. Just inform the controller it had been switched off.

It might be necessary to add some overriding functionality (eg. keep relay on for x minutes if it has been switched on using the button and so on).

@pdp8 Despite not beeing familiar with domoticz, this behaviour seems to be logic to me: You presentet a light device, so this typiclly is switchable from controller side.
You might either change the handling within domiticz or present a different Child Type (my code uses motion).

Seems to be a good starting point, but some remarks:

• Using PINs 10-12 might not be the best choice in case you want to add a radio later (my code was for RS485@HWSerial)
• Doing this kind of task using arrays gives much more flexibility and easier reading imho

So essential Part of the sketch could be reduced to something like (untested, changing PINs recommended):

...
#include <Bounce2.h>

#define FIRST_PIR_ID 1
#define MAX_PIRS 3 
const uint8_t pirPin[] = {10, 11,12};   //  switch around pins to your desire
Bounce debouncer[MAX_PIRS];
MyMessage pirMsg(0, V_TRIPPED);
bool oldPir[MAX_PIRS] = {false};

void before()
{
}

void presentation() {
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo(SN, SV);
  // Fetch the number of attached temperature sensors

  for (int i = 0; i < MAX_PIRS; i++) { //i < numSensors &&
    present(FIRST_PIR_ID + i, S_MOTION);
  }
}

void setup()
{
  for (uint8_t i = 0; i < MAX_PIRS; i++) {
    debouncer[i] = Bounce();                        // initialize debouncer
    debouncer[i].attach(pirPin[i], INPUT_PULLUP);
    debouncer[i].interval(5);
    oldPir[i] =  debouncer[i].read();
  }
}

void loop() {
  
  bool pir[MAX_PIRS];
  for (uint8_t i = 0; i < MAX_PIRS; i++) {
    debouncer[i].update();
    pir[i] = debouncer[i].read();
    if (pir[i] != oldPir[i]) {
      send(pirMsg.setSensor(FIRST_PIR_ID + i).set( pir[i])); // Send tripped value to gw
      oldPir[i] = pir[i];
    }
  } 
}```

Just concentrate on the looping over arrays logic, then it's not that hard to break the link between the buttons and the relays. Did this myself here, despite having a lot of other stuff done there maybe this helps

IMHO this is a good starting point: https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33

@pictor-lallemand You may also have a look at the sketch @korttoma published in post #33. It does exactly the same than yours, but in case one needs more or less relays, it's much easier to adopt .

Interesting project. As I'm just a hobbyist, there might be be better solutions and thoughts, but that's what I know:

First: I assume, in case of yarn breakage you will have to stop the machine and some human will have to fix the problem - so some kind of lokalization of the breakage would be sufficient? => Put an array of hall sensors to be easily checked with one view in parallel and use hall sensors that will be switched on in case of breakage. This reduces the amount of PINs or other detectors needed.

As I'm not familiar with the mentioned D2401: Just order some of them for testing... Don't know how fast they are, but wrt. to 1-wire Temp sensors I know 1-wire is at least capable for some dozents of them on one bus. Several buses in parallel are posible, bt then memory might become an issue.

You may also have a look at port extenders like the MCP23017: this gives you more PINs over a simple I2C connection, several of them may be used on one arduino (no experience with that). They offer interrupts also afaik - if speed in reaction is needed. Most likely you might need a more powerfull mcu - then have a look at the STM32's (but avoid blue pill in favour of maple mini-compatible solutions).

@reshma-oueseph said in Multiple sensors:

Thanks @rejoe2
Another doubt rises , while i am surfing related to this
Does it possible with I2C bus protocol ?? or using relay ??

Sorry, but I most likely don't understand the question.
I2C is designed for short wires, so most likely this will not work over longer distances usually to be covered in a buidling. But you may use one or more I2C multiplexer devices to add more PINs to the arduino - but then you will need one signal line to each of the hall sensors.

A relay is actively switched - so this is an output topic. According to your fist post, you where looking for an option to get info from several input devices on just one PIN.

As a personal remark: as your seem just to begin to build up knowledge on all these topics you may try to find someone willing to explain all these things face to face - speaking the same language and using also some basic equipment to demonstrate how things work. Doing all by yourself you might get frustrated very fast.

@reshma-oueseph 1wire and hall sensors are not the same.
A hall sensor ist just something like a switch, so it's hard to identify which one has been opened (or closed) as all of them just give back some kind of power (or no power) signal.

To get out of this, there seem to exist (at least) two ways: Either put different resistors in the output lines and try to distinguish by the analogue voltage you get back or
put some active component with identification option to be switched on on the output. Here's a proposal to use DS2401 to be switched on by NO-reed contacts. But to identify which one has been switched on or off on an arduino base may be hard work to do, especially if you'r new to all that stuff.

EDIT: the latter seems not so tricky as expected - at least in case this lib and sketch works: https://github.com/Julius2342/DS2401-control/blob/master/examples/Simple/Simple.pde

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?

@avamander If you want more than just collecting data, you may also have a look at FHEM. This is a rock-solid piece of software written in Perl (this indeed is very special) allowing to virtually connect anything with IoT-capabilities and steering it.
But not everybody likes it's look and feel. This is getting better using the new "f18"-Design, but still it's imo more targeting towards those wanting to get things done in the background. For UI design, there are also several options, but this needs some "hands on work" to be done.
But eg. grafana is also supported as well as logging using all kind of SQL-databases.

Despite most of the forum post are in german, english questions will also be answered in most cases

You may use virtually any other type of sensor as a child (apart from the ones representing percentage values). I fyou want to have it bidirectional, use one your controller is able to send. In most cases S_CUSTOM is a good idea, but eg. FHEM will then provide you with 5 variables to exchange info between controller and node - that may be to much.

Everything's working like a charm now , so thread is marked as [solved] now.
One more big "Thank you" to everybody helping to get this finally done !

In addition a picture of my Node 2 - the one I did the most rework over time until now also showing the violet MCP2551 module mentionned above.

Thanks for helping @seeers at Github.

Still no communication issues to report, so just two additional remarks on the MCP2551 usage following some short tests on that:
They also seem to work at 9600 Baud and also using the MySensors standard (AltSoftSerial at PINs 8 and 9) is possible.

So for now, I'd recommend everybody thinking about new nodes to give this type of hardware a try. The only disadvantages may be

• the limitation in payload - but that seems not to be any practical issue in the use in an MySensors environment
• they might be more sensitive in crossing BusHigh and BusLow connection, so make sure all highs are on the same wire and also all lows

My favorites are kind of violet modules. Didn't come across them earlier, so I'd see all PINs on one side as a modest point for improvement. As there are also no resistors at all, just pads for soldering, there's also not the need of starting with desoldering unnecessary parts - just make sure, you have the right stuff to add .

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!

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

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!

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

The radiowave based ones are imo better wrt. that, so why not give them a try?

According to my experience results depend much on the environment, especially wrt. their ability to "look" through walls. If it's bricks without holes, you may get also satisfying results.

Besides all other things a stable power sourcing seems to be essential . I use 5V, but some report also satisfying results when sourcing the IC directly with 3.3V.

There's the option to reduce responsiveness also by adding a resistor, more details can be found here.

@qobouky First: using more than one SPI device on one MCU is possible - this requires just some more preparation e.g. in before() in case of using the same SPI interface (initialising other SPI devices prior to nRF will be addressed through the MySensors libs in presentaion() and setup()).
If you plan to use a LCD screen, you may need a more powerfull MCU like the ESP or an STM32 (th later offering also more hardware SPI interfaces). There are some examples available you may use as a reference:
https://www.mysensors.org/build/dollhouse#tv-node
https://www.mysensors.org/build/scene_controller

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

@btmerz If the controller is not present, the nodes won't enter loop(). To avoid this, use (3000 may be changed)

#define MY_TRANSPORT_WAIT_READY_MS 3000

@nofox Did you measure voltages on the bus?

Some additional info: I did some futher experiments using also MCP2551 as transceiver chip. As they are PIN-compatible to the TJA's, it was just a modification of the modules. I can confirme thess also to work.
General "restriction" is one has to use HW-serial. For me, that's ok, but if you want serial output for debugging, you also have to use altSoftSerial and use it for debug output.

This morning, I replaced the end-of-line module with a resistorless one (so also NO termination resistor is used on this side, only at the GW!).

At least, the Bus is working for some minutes now @56700 with just GW (MAX487) and one node for each of the tranceiver chips (MAX487, MCP2551 and TJA1050).

If that works more reliable, I'll switch all nodes to MCP2551 and lower the transmission rate, most likely to 19200 Baud. Will take again some time, but I'll keep you updated. For this I plan to use a STM32F103 as GW, if possible, I'll try to expose also the other two Serial Interfaces to the OS, so one could attach up to two other GW's (for other physical transport layers) to the STM using just one USB connection. But that's another project on another planet and if there's someone out there with more experience on how to do that: Thank's a lot...

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

@joaoabs If you want to go the "arduino-based" route:
There seem to exist already a lot of projects reading this type of meter with a microcontroller e.g. an ESP8266.
The code itself seems to be rather simple (assuming, the code provided eg here: https://github.com/reaper7/SDM_Energy_Meter/blob/master/examples/sdm_simple/sdm_simple.ino really works, but there seem to be some more working projects out there).

So you may either combine this with normal mysensors-code and just use send commands instead of serial prints (at lower frequency). Could be you'll need a more powerfull mcu than the ATMega32, but most likely a STM32F103 will have enough resources to fullfill this task.

@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

@mick Thanks for coming back to this topic, the stuff arrived already some weeks ago, but unfortunately I was busy with other parts, amongst them btw. a modification of the MySensors plugin for FHEM to get probems shown more easily. So finally some soldering work was on my list yesterday. So today there's the option to at least give some first impressions on that:

• Network is @57600 for the use of the TJA1050 modules.
• Soldered some adopter boards for direct replacement of the modified LC-Tech MAX487 modules, (crossed RX/TX as usual, there's no DE/RE, later also desoldered the 120 Ohm resistor)
• plugged it in Node_2's socket, and

WOW: It worked!

Tried a second one on the same node (module without the 121R): Also worked

So I continued and tried to teplace the transceiver at Node_3 with the tested (now resistorless) one:

NO LUCK!

Continued with the last transceiver in line holding the pullup/dow resistors: Also no luck

So I decided to stop at that point to see how Node_2 will perform over night and meditate on the question why the behaviour on the other two nodes is different. Kept Node_1 and Node_4 not connected to the bus, so starting the experiment just with 3 nodes and the GW online.

This mornings's findings:

• (Node_2 hat at least once spontanously rebooted, but still was sending in data. I's rate this as some kind of partly success, but obviously the node needs to be reviewed, there most likely exists a problem not related to RS485.)
• (Node_5 was offline for whatever reason, no issues - as always - on Node_3)
• These transceivers can be used for MySensors@RS485
• They can be used in a mixed network together with normal transceivers
• BUT: (hypothesis) They may not be used in combination with altSoftSerial; Node_2 is HW-Serial, the other two still use software, so for them DE/RE might be essential (ISR?)

Additional remarks: I tried also a different power source for the 12V a couple of weeks ago - no difference (MAX487-only bus)
The GW was online during all of the time, it's uptime is 7 days by now (also SW-serial).

So I'll have to do some more testing on some of the topics and perhaps also build some more test nodes to avoid touching my "normal" bus too often - this seems to also cause additional trouble...

I'll come back when I know more, but again, this will take some time.

@bakcsa Thanks for this great summary!

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

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

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

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

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

Two remarks:
Both of my serial 2.2-GW's stay at "startup complete" and are working as expected (seems to have changed somewhen in the development of 2.0). Trying to set them to "connect" causes a reboot ending again in "startup complete".
So this is not really a fault, just let them state "startup complete" and don't worry too much about that.

If the Arduino really is spontaneously rebooting, this could also be due to a fault in the Arduino design (Test PION floating). But as you described the "problem" shows up also with the adapter/pro mini version, this seems not to be the case here.

Perhaps using a different microcontroller could also be an option?
I'm personally not to deep in these things, so this might be completely wrong, but at first sight I'd try to get this working with a STM32F1 board. Seems that using them in conjunction with direct access to the ADC might speed up things, see http://wiki.stm32duino.com/index.php?title=API#Reading_from_.26_Writing_to_pins as a short reference.
And using MySensors with STM32F1 seems to be used by several users here.

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?

Didn't test this, but using a vibration sensor (modules are available under the namee "SW-420 Vibration Tilt Sensor Alarm" at big market places) might also be an option. Should provide digital and/or analog signals.

Best success with your project!

@gabriele-cirillo said in More relay and push botton:

ps: i deleted what??!?!?

Your code was to some extend very close to @korttoma's. So I thougt you started with a "cleaner" version ot this base and let out some parts - especially things related to

#include <Bounce2.h>

To me, these things are also quite close to magic, don't worry .
I don't know, what is going on at bootup, but my assumption wold be the PINs are somehow floating, as you didn't do some kind of initialisation in setup() or comparable.

Add. remark:
You also deleted the original debouncing function - that's possible, but as you seem to be quite good in adopting things (imo you made a big step forward). So you may review your code once more wrt that; could be the debouncer-function does a little more than just wait some time .

OK, this is a different topic: as long as there is no uplink to the controller, your sketch will never enter loop() and so on.
Sounds like there is no radio module attached? Please see hints in troubleshooting, especially: log parser.
As a workaround you may get node starting without radio by using

#define MY_TRANSPORT_WAIT_READY_MS 3000

But some remark wrt applying fixes like that: It's kind of frustrating to discuss basic things when beeing asked for help on really advanced features. Imo, you might get some more basic examples to work first before starting projects like the one here.

Just my2ct...

@gabriele-cirillo Can you please be a little more specific: What exactly is not working? What's the serial output?
I have to admit, I never directly used @korttoma's sketch directly, but used the principles he applied to make own things happen. So if you want to dig into this a little more in depth, you may have a look at these here and here (the later not yet finisched, but button+relay-wise working).

@gabriele-cirillo Sorry, but the one you posted may be the sketch of the first post in the linked thread, but my link (at least on my computer here ) leads to a very different sketch using arrays for assinging PINs and buttons. See post #33 by @korttoma in the linked thread.

@gabriele-cirillo Can you please reformat your post using code tags (</>-button above the editing field)?
Wrt. to your sketch: Why do you use different childIDs in the receiving part than in the header?
Did you have a look at the sketch in the above link? You will have to learn a little, how to use arrays, so please first try to understand how it works. I agree, this is not a very simple example, but as you asked for one...
Don't really expect me (or somebody else) to deliever completed code - in the end it's up to you to connect your buttons and SSR's to the arduino, so you should know, what you are doing .

You may have a look at this example here to avoid redundancies in your code: https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33#

@dirkc said in Multiple Relays + Motion sketch, fully customizable, optional timer, manual override:

@ostoja said in Multiple Relays + Motion sketch, fully customizable, optional timer, manual override:

// Present all sensors to controller
  for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {   
     present(i, S_TEMP);
  }

  // Register all sensors to gw (they will be created as child devices)
  for (int sensor = 1; sensor <= NUMBER_OF_RELAYS; sensor++) {
    present(sensor, S_BINARY, "Relay", ack);
  }

With this two "for" loops you set present(n) multiple times. in the first for() you start with 0 until MAX_ATTACHED_DS18B20-1, in the second for() you start with 1 until NUMBER_OF_RELAYS-1
I have not checked the internal code of this method, but I would think that you should better user a different range in the second for() loop starting at least with MAX_ATTACHED_DS18B20+1.

Additional remarks:
For the relays better start with 1.
Shift the Temp values to higer range (use e.g. a variable like FRIST_DS_SENSOR_ID).
Check, if the receive()-part and the ID you get really fits together with the relay you want to switch.
Don't try to read the temperature values every few parts of a second. Use a millis()-routine.

Please search the forum, there have to be at least 2 threads with exactly the same problems in which I posted how to solve this. You are "trying to reinvent the wheel".

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

Just in case the Arduino you use for the GW is also equiped with an FTDI USB-serial chip:
Check wheter the test pin is correctly set to GND. The TEST-Pin is # 26 on the FTDI-IC and can be soldered together with neighbouring AGND (PIN 25).
Some background info: your controller resets the GW when connection to serial. If your board is suffering from this issue, TESTPIN bay be floating, and this finally leads to an endless reboot.

@suresh-mali So then last ideas could be the gw version: is it also 2.2.0?
What kind of RF are you using - if it's nRF24 and you are already using the recommended caacitor, the MySensors lib version really could make a difference. For other RF modules, you may have a look at recent changes (RFM69 new driver).

Beside that I'm also running out of ideas.

@suresh-mali said in Node unable to get ID from gateway. [2.2.0]:

!TSM:FPAR:FAIL

Seems like there is either a problem in the RF part (node could have a defect transmitter) or your controller is not accepting new nodes. This is partly controller specific, eg. in FHEM you have to set the GW to "inclusion mode" AND have to activate a feature called "autocreate".

@makin Ok if you're really sure the problem is located on the node, you may extend debouncing time as already proposed.
I also saw other examples of debounced PINs issuing a "pinMode(buttonPin, INPUT_PULLUP);" in setup() instead of digital.write(HIGH). Could also be worth a try (in case this is valid for an ESP).

So you may first have a look how the message processing really is done at your server.

In general I'd avoid that kind of signaliszing in an industrial environment. The ESP8266 isn't the most reliable kind of mcu to use and wifi for transmitting simple counter data causes a lot of unnecessary overlay. Use at least wires instead...
You may also add some kind of plausibility check like adding a counter value to the node also and send count values to your server after longer periods (e.g. every 5 minutes). So you can compare what was sent from node and what had been received.

Am I missing something, or is there no real counting code on the node?

If it's really like doubleing the real values, you may also count the "off" messages at the controller/receiver side.

Additionally: If it's really something like 2-3 parts per second, it's 4-6 changes. So you may better choose a somehow longer interval for debouncing (15 or 20ms).

@daniel-ruiz9
Interesting build. As you seem to like to have your "own" stuff and use a CP2102 as USB to serial converter you may be interested to assing also an individual name in linux USB filesystem. There's a pretty simple tool to use here. Then you may get something similar like "/dev/serial/by-id/usb-Silicon_Labs_myHMUART_0001-if00-port0" to identify your GW. Comparable to FTDI-based GW's (using this tool under linux, FTDI offers a MS programm also):
/dev/serial/by-id/usb-MyS-GW-RS485_001-if00-port0@115200
/dev/serial/by-id/usb-FTDI_MySensorsGW_002-if00-port0@115200

@suresh-mali No, this is the one writing zero's. Use the one that comes with mysensors (or assign an ID manually in your sketch, this may lead directly to a working node).

@suresh-mali said in Node unable to get ID from gateway. [2.2.0]:

I also cleared EEPROM

The question was: how did you do this? There are - as already mentionned - two sketches available, but only one works .

@daniel-ruiz9 There's some trouble while initialising your radio module, see log parser (https://www.mysensors.org/build/parser). "!TSM:INIT:TSP FAIL" means
Transport device initialization failed
So check your wiring (and general powering) or try a different module.

@suresh-mali said in Node unable to get ID from gateway. [2.2.0]:

10053 !TSF:SID:FAIL,ID=0

Did you use the standard arduino Clean-EEPROM-Sketch or the one that comes with MySensors? The first writes "00" in EEPROM, the later "FF".
For analysing this kind of trouble also the https://www.mysensors.org/build/parser is a very valueable tool.

@gohan Effectively, he will never report any temp reading under ChildID 0. Within presentation() and the send() commands, the "0" is replaced by "i + DS_First_Child_ID".
But you are partly right, to avoid any misunderstandings wrt. that the statement could also be written as follows:

MyMessage msg(DS_First_Child_ID,V_TEMP);

OK, there seem to be others out there with similar problems, and I'm rather sure, the hardware I used the last days was also working before...
Can't test it, but this may be related to the recent changes in boards.txt (did you do any updates on that the last days?):

https://github.com/arduino/Arduino/commit/1cf34c8250658c5c4a5c488f7a7a0d7071e3430f#diff-4ead488680453362ffec01d74609315c

So you may either try to use the "old bootloader"-Variant (didn't work for me), try to upload a different bootloader or try, if changing just the upload speed back to 57600 Baud may help.

Good luck and keep us updated how you solved that problem!

3 facchinm committed to arduino/Arduino

Add menu for Nano with Optiboot bootloader

Since we are now factory flashing obtiboot, 115200 is the new default upload speed. Adding a new entry to CPU menu is more explicit than adding an "upload speed" menu, and the bootloader path can be updated too.

Fixes https://github.com/arduino/Arduino/issues/4492

@lekeb
You may do something like this:
In Header:

uint8_t DS_First_Child_ID = 7; //First Child-ID to be used by Dallas Bus

an then in presentation():

for (int i = 0; i < numSensors && i < MAX_ATTACHED_DS18B20; i++) {
    present(i + DS_First_Child_ID, S_TEMP);
}

But afaik, it's not recommended to shift the ChildID's for relays but always start with 1. Imo it's better to change the ChildID's of the other attached sensors. You may also take care (in case of shifting ID's) about a consistent mapping from ID to the PINs where the relays are attached.

@kimot Thanks for clarification, just ordered a bunch of TJA1050 modules and a couple of naked MCP2551 (seem to be pin compatible with the TJA's) . That may take some time for all the way from china (new year is coming...).
Next step then will be to change Baudrate to 57600 (seems to be the upper limit when using software-serial - as needed for my Nano-GW. Btw.: I did some really disappointing tests with a pro micro-GW, but that seemed not to work, I most likely will have to make another attempt on this to use HW-serial ).

Then I'll replace the MAX48x-modules by these TJA's and see, if everything's fine then.

Just one remark: If it's as easy as that, wouldn't it be good to just recommend using that type of module as a standard instead of the problematic standard RS485 types?

EDIT: One more question: Mixing both (or all three) types of transceiver should be possible, or am I wrong? (This would not completely eliminate the MAX485-disadvantages, that's clear to me)

@kimot Thx for reffering to CAN.
Some questions and remarks on that:

• The Node ID's assigned in reality are 97 and higher, the node-# mentionned here are just for simplyfing explanation by following the physical order they are attached to the bus.
• How to setup a CAN network with MySensors? I saw some suggestions wrt to that in the past, but that seemed not to be "ready to use" code and hardware. So is there an option to just replace the MAX48x by a different chip and use the MyS-RS485 communication layer?

I have some MCP2515 modules laying around, but these use SPI as connection towards the mcu and would require an appropriate communication layer in the sketches (at least as far as I understood).

But in general, also standard RS485 claims to be robust and not rocket science tech. So it's really frustrating to experience that amount of problems and backdraws.

EDIT: I found this thread: https://forum.mysensors.org/topic/5327/can-bus-transport-implementation-for-mys. Most likely, really understanding most of it's content will need a lot of rereading. But as far as I understood, integration of CAN still would need a lot of development?

@zachflem said in NOT WORKING: DHT and RELAYS on Ethernet GW:

any thoughts?

Not sure about if that's still valid, but there had been the recommendation to use ChildID 1 for the first relay. So you may use 3+4 for temp/hum or start with 10, 20 (or whatever you like) as proposed to have room for further relays or other type of switches.

@gohan I absolutely agree. Wrt to wiring: Most of the wires I use are twisted pairs of CAT6 network cables (one pair for signal, and - when distributing also 12V - one for 12V+GND). Some newer parts (trouble began before that) are 4 wire telefone wires with around the same copper diameter per single line.
Connections: Just one Wago between GW and Node_1, the others are either directly screwed using the modules or build short stubs (<20cm) from a Wago clamp with three connections (in/stub to node/out).

So if you see room for improvement, suggestions are welcome

@zachflem said in NOT WORKING: DHT and RELAYS on Ethernet GW:

I'm also only getting the humidity presented to MyController

This also indicates some trouble in the communication between GW and Controller. For debugging, you may also add some wait()-time in between the presentation of the individual child-ID's.

So once more a short update: No significant changes achieved by changing the transmitters and the placing of the resistors - only two of 4 nodes are working as expected , the 5th (Node_2) is still turned off to prevent possible interference with Node_1.

As two of them are online since my last post (around 18 days), I'm quite sure, it's not a gw issue as @pjr reported, and as one of the nodes is powered from a different source than the other 3 and different than the GW, it seems also not to be powering related. So I'm a little running out of ideas how to further debug .

Now', Im thinking about reverting Baudrate back to 9600 and - in case this will not help (what most likely will happen) - splitting up the bus to two lines, this may help to find out what is going on with individual nodes.

So @otto001 At this point in time I'd say: It really depends...
If you have only a few nodes (2-3+GW) you want to attach, RS485 is a simple and secure option. But as soon as there are more, one failing will affect the entire communication - that's really no fun. So stay with nRF24 (or other wireless transceivers) for nodes just sending in data and try RS485 with a few important switching/security relevant nodes first.

Just my2ct...

@fedyn Thx for reporting back. Just in case you expect anyone to help you further with this, it is necessary to post updated code together with more info what is "not working" (here: the switch/lightning part or the DHT).

You may also find some more hints in how to combine relay and non-blocking loop() starting here: https://forum.mysensors.org/post/81401

Btw.: you mentionned 2 DHT in the title of your post, but in the code, there's only one.

@fedyn First remark: as working at 230V mains is dangerous you may think about leaving the 230V always on and use the 12V also to power the arduino and switch the LED on using a MOSFET (relay may also be ok).

Wrt to your sketch, imo you should not combine sleep() with a debouncer-design for your switch. The debounced PIN (your button) then will not be read while sleeping.
You may either have to use a non-blocking-loop() (example how to do this: see the https://www.mysensors.org/build/pulse_water - sketch) or use PIN 2 or 3 for an interrupt-based solution (following the https://www.mysensors.org/build/motion - example).

@gohan said in NOT WORKING: DHT and RELAYS on Ethernet GW:

"Wait" will keep the rest of the GW functions running, it is not like "delay" that blocks the code execution

Thx for clarification

@gohan The reason behind proposing to use a non-blocking loop() was as follows: The former gw.process()-function has been pushed in the background so it is no longer visible directly in the sketches. But nevertheless I thought, for GW's and repeaters it still is highly recommended to go through the loop() as often as possible to avoid any delays in the processing of ingoing messages.
The proposal to just use wait() is not really compatible with this understanding of the internal machanics of MySensors. Did I get something wrong?

Not sure, if this is really the cause of your troubles, bit imo it's not the best way to measure the DHT values every time when loop() is gone through. Doing so, the arduino most of the time is just waiting for the DHT to finish measurement.
I'd recommend to use a non-blocking-loop() function - you may use the https://www.mysensors.org/build/pulse_water example to build your own code or search the arduino website for non-blocking loop.

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

Short update, thx for reminding me there's still work to do :

• Moved pullpup-/pulldown resistors (440Ohm) from one end of the network to the other (now: GW).
• Replaced all MAX485 with MAX487 (all placed on LC-Modules, most of the resistors 5-7 are desoldered, the 120Ohm's remain only on GW and last node).
• SOH-Count is now set to 3 on GW and Nodes 1 to 3 and 5, so only Node 4 (BME280) is remaining with default (1)

At first sight, everything's working, and node 2 for now seems not to fail as soon as the last time before these changes; but as always: If this is really reliable over time, we'll see. So expect at least one more update, hope this will be the last

@mfalkvidd Thx for doing some deeper analysis.
Until now, to me the data from the BME280-node seemed also to provide plausible data. My "reference" is a DS18B20 attached to another node installed at a different - less exposed, so also less accurate - place.

Used lib is the BME280-lib by Tyler Glenn that comes with Arduino (Version 2.2.1, as latest 2.3.0 seems to be broken with AVR).

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

@pjr Short story: Still no satisfying results, but to be honest, I didn't spend too much time on that for now. The - for the moment - most important part (Node_1) works pretty reliably, the others I have to restart from time to time (Node_2 is always the first to fail)

Longer story:

• ordered some MAX487 chips to replace the MAX485 - this took some weeks from China and they still need to be soldered when there's time to do that...
• GW (seems to work reliably by now):
  -- tried to use a Pro Micro with hw-serial as gw - didn't work as expected, I reported about that some weeks ago (may have been in the fhem-forum).
  -- Next step is to review it (Pro Micro, Nano or STM32F103) once more when replacing the transceivers and do some testing wrt resistor values
• The timing on the nodes may also offer room for improvement - by now, my plan is to really delay the startup procedures (or the first measurement) and nail the measurement times to a fixed value. This may avoid overlap of the nodes sending slots in direction to the gw as much as possible.
• last step could be a review on powering issues, seems Node_1 at some point in time suffered from issues wrt that; maybe there are other nodes with similar effects too (all nodes have a lot of wires attached).

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

@mfalkvidd Thx for the "quick and dirty" way. This at least is a starting point, but most things around that seem really to be hard coded (MySensorsCore.h: L77: GW Address is 0 is the point where the getNodeId() finally leads to).
But if that really works there might be a way to wrap around that - but indeed this seems to be quite complicated.

And indeed, you are right that having multiple nRF-GW's was possible ever since MySensors existed.

@mfalkvidd said in Mulitple Gatways and NodeID0:

Hack away on the code and see what your impression is.

To be honest: It's already hard work to me to get a more or less clear picture how all these parts of the "big puzzle" fit together... But doing this type of coding most likely is far beyond my knowledge .

As a side note wrt controller capabilities: I don't really believe this "limitations" are only affecting FHEM - this seems to be have its roots in the times MySensors was "only" using nRF24 as transport. Then, having multiple gw's was not "on the list" of most of the implementations.

Just in case I really dare to digg into that: Do you have a hint for a starting point in the code to look at?

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

@mfalkvidd The Problem imo is that as far as I understood, sensors attached directly to the gw will be reported under NodeID 0 - regardless if one tries to assign a different one.

At least FHEM then will mix up these infos from different gw's and build a "virtual" Node 0 combining the infos sent from each gw.

For other nodes, this can be avoided, as one can assing a really individual ID (and in FHEM assign the right path in filesystem to the corresponding gw to make sure communication works as expected).

So from FHEM's point of view, it would be desirable to distinct between real gw functionality (that has to use ID "0") and the "other" part ("ordinary sensor functionality) allowing to handle that as a seperate unit and address this under a seperate ID (in case if needed).

(Hard to explain, hope, you got my idea).

I'm not sure whether this is problem of the MySensors serial API or more a controller specific topic.
Didn't test that in depth, but at least FHEM seems not to destinguish between Children on different gw's.
How are experiences with other controller solutions?

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

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

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