Three remarks on that:

• Avoid doubleing ChildID's for temperature and relays (1-3 are "dual-functional", DS_First_Child_ID = 4 would help)
• Use wait(conversionTime) instead of sleep(conversionTime); millis will otherwise be reset.
• Better use FHEM's options to request an ACK from the Node; so state will not be update on controller side until ACK is sent from Node. (send(msg[message.sensor].set(Relays[message.sensor].relayState ? true : false)); is not needed; in FHEM: attr <MYSENSOR_0?> requestAck)

@qobouky said in MQ135 with RS485:

!TSM:FPAR:FAIL

This basically means there's no communication between the node and GW.
Note: at RS485 transport layer, automatic NodeID assigning methods for the nodes will not work, so you have to do it manually.
Just saw this even isn't mentionned in the RS485 motion sketch example.

@allysmith Please check if you use the right MCU frequency.

@wimd In case you are looking for an option to check if the GW is available: There somewhere is an option to check, if uplink is available. Don't have a link by hand, but search for that, there's somewhere at least one sketch in the forum offering that (light-switch afai remember).

@kimot This consumes a lot of PINs, so it's a question what kind of trade-off you are looking for.
As the 1Wire sensors have the option to address them correctly, I really like the advantage of reducing bus numbers. Just to remark: I also have at least one node running with 3 1Wire PINs - but each with a different timing . But if you are just worrying about replacement of single sensors, use something like that: https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency. That only needs a restart between eacht replacement .
Or add OTA features to your nodes...

@dzjr Did you also try with the default value ("0") instead of 3000?
I'm not familiar wir domoticz, but the need for another wait looks like a strange behaviour to me.

@zerosquared
Imo there's not really a problem with the sensor itself but with the transmission towards the GW.

8696 !TSF:MSG:SEND,1-1-0-0,s=0,c=1,t=1,pt=7,l=5,sg=0,ft=3,st=NACK:56.64

The only exception in your log is wrt one temperature reading. So have a look at the troubleshooting guide; especially use a capacitor to enhance power sourcing of the nRF modules.

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?

@dzjr said in 2 dallas temp + 4 relays:

MY_TRANSPORT_WAIT_READY_MS

This flag is - amongst a lot of other stuff - explained here: https://www.mysensors.org/download/sensor_api_20.
So putting it to (default) "0" will keep the node looking for an uplink to the GW until that one is really available. As I don't want that (my nodes have some logic of their own, I want to work independently), I added that. But in case, it's just sensors and so on, I'd recommend to stick with the defaults.

Wrt. to the "metric"-topic: Please do always have a look at the entire sketch. In my sketches, typically the metric variable is just initialized once in setup(). Eg. in the array-sketch you'll find that in line 97.
If you are looking for a "easy" way to replace single sensors and keeping the original order of the others, have a look at this one.

Good work, @TheoL!
Some additional remarks intented for @dzjr form my side:

• Do you really want to start the node also when no communication to the GW is present? Otherwise disable "#define MY_TRANSPORT_WAIT_READY_MS 3000"
• calculation of the conversion time could also be done once
• using an array containing all of the sensor addresses makes code even more easy to read.

For the later two things see https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency/blob/master/Dallas_Addresses_Array_Solution/Dallas_Addresses_Array_Solution.ino (hope this still works, there had been some changes in the dallas-temp lib since I last used it myself).