Yeah, companies want you to buy their own gateway to lock you into "their" ecosystem. Some ecosystems, like Philip's hue for example, at least allow you to add a limited set of third-party devices to their system. But generally, as long as the ZigBee devices follow the protocol, which most do, they should be able to co-exist in a single network - it's just that most commercial vendors don't seem to want that.

Luckily, as rejoe2 mentioned, there are open source ZigBee stacks like Zigbee2MQTT or the Home Assistant-centric ZHA, which allow you to manage all your devices from a unified UI / HA controller.

I personally use Zigbee2MQTT together with a Sonoff Zigbee Plus Dongle (powerful CC2652P) and have devices from various vendors connected. Philips hue and Innr LED bulbs, Osram plugs, some Chinese radiator valves, Xiaomi thermometers,..

There are websites that list which Zigbee devices are compatible with open ZigBee software stacks, with information about how to set them up, etc:
https://zigbee.blakadder.com/index.html
https://www.zigbee2mqtt.io/supported-devices/

@pikim No, I am not. My original plan was to deploy more and more RFM-based nodes as they seemed superior over NRF24 in general, but I realized that my NRF24 network was rock solid and reliable, so there was no need for the added complexity and cost to support and integrate another transport. Plans are made to change them. ;)

That being said, I used the multiRF gateway for months without issues. The gateway operated as stable as the single transport 2.3.2 gateway. No issues at all, except with the automatic TX power adjustment (ATC) of the RFM transceivers, due to what I believe might be a timing issue within the library. I described the issue in this thread. Basically, the RFM nodes were not able to reduce their transmit power, unnecessarily blasting the environment and wasting battery power. Introducing small delays in various places was all it needed to work around this issue successfully, seemingly without adverse side effects.

This issue has not been properly remedied since the introduction of the multiRF gateway though. For all I know, it is still tekka's personal fork of the MySensors 2.4 branch and has not been updated, so any new fixes and features for version 2.4 since March 2020 will not be available to this fork, unless you manually implement them.

So I guess it is up to you if you prefer to use the multiRF gateway without all the mainline 2.4 changes, or the up-to-date 2.4 branch without the multiRF feature. It should not make much of a difference currently, according the the commits since the multiRF fork, unless you want to use PJON transport or deploy NRF5-based nodes.

I really wish that the development on MySensors revives, as it is feeling kinda stale at the moment. It would be a shame if this project got silently abandoned. I would be glad to help out wherever I can.

No, Home Assistant didn't render battery-powered nodes unusable.

I have never used the optimistic mode in Home Assistant, yet I'm able to achieve uptimes of more than a year with CR2032-powered (merely ~230 mAh) MySensors nodes. See here for an example. The temperature sensor I mentioned there is still working since April 2020, reporting every 5 minutes.

In which use case would the optimistic mode be necessary?

I mean, you have full control over the node's behavior. If you want to go as easy on the batteries as possible, you can put a node back to sleep as soon as it has sent a new measurement once, without waiting for any feedback. For more critical sensors (i.e. security-related) and actors on the other hand, you probably want confirmation that the data was successfully received and rather replace the batteries a little bit earlier, don't you?

@Marek If you only copy and pasted the above two lines into your config, then you got that error message because it is an incomplete configuration for the old, YAML-based MySensors integration.

A valid YAML configuration looks, or rather looked, like this:

mysensors:
  gateways:
    - device: mqtt
      persistence_file: '/config/mysensors.json'
      topic_in_prefix: 'mysensors-out'
      topic_out_prefix: 'mysensors-in'
    - device: mqtt
      persistence_file: '/config/mysensors_testing.json'
      topic_in_prefix: 'mytest-out'
      topic_out_prefix: 'mytest-in'
  optimistic: true
  retain: true
  version: '2.3'

You may be able to set the optimistic setting by adding something like this to your config and restarting Home Assistant. You may also need to delete your existing UI-based integration beforehand.

That being said, the old YAML configurations are not recommended (and apparently neither documented) anymore. When a YAML-based MySensors configuration is detected after a HA start, it will be migrated to the new UI-based integration automatically. Subsequent changes to the YAML config will be ignored.

AFAIK, the new UI-based intregration deprecated a bunch of configuration options and I think that the optimistic setting is one of them. I don't know of a way to set it using the UI-based integration, nor if it'll be carried over by importing an "existing" YAML config. The documentation of the MySensors integration may be incorrect / outdated here.

Hmmm. Unfortunately, that "connection lost" line is to vague for me to draw any conclusions.

Have you had a chance to look at the gateway's serial log when it lost connection to Home Assistant?

What version of MySensors are you running by the way? Maybe it's worthwhile to upgrade to 2.3.2 if it isn't already. Home Assistant is also up to date?

The next steps that I would take would be to ...

• Check that both MySensors and Home Assistant are on a recent version
• Watch the gateway serial log for any hints (using a remote debugging library or hooking it up to a server / RPI and writing the serial output to a file)
• Ensure that the power supply is fine and maybe even replace it temporarily, just in case
• Consider adapting the gateway sketch to MQTT (or even serial) and see if the issue still comes up

Well, MySensors doesn't care at all about units when you send a message. It gives you the freedom to measure and send whatever you like. Be it temperature readings as °F, °C, °K or even °Re.

Note that MySensors is just the communication framework. Everything else needs to be handled by you, the sketch developer. You handle the sensor interaction and - if necessary - do the required unit conversions manually or with the help of a suitable Arduino library. Just as you would in other non-MySensors projects.

Let's say you want to get the temperature from a BME280 sensor and use SparkFun's library to interact with it. If you only care about imperial units, call the readTempF() function they provide to store the temperature in Fahrenheit in a variable and send it to HomeSeer.

BME280 bme;
MyMessage msg(CHILD_ID, V_TEMP);
//...
void loop()
{
	// ... every 5 minutes ...
	
	float temp = bme.readTempF();
	msg.send(temp);
	
	// ... return to sleep ...
}

No controller configuration required, and that's totally fine. The vast majority of MySensors users would do it this way.

While MySensors doesn't care about units, as I mentioned above, it still enables you to check which system of units the connected controller wishes to receive using the ControllerConfig object. With this, you could write sketches which conditionally send different values for those users who use a controller with imperial units than those, who configured it for metric units.

BME280 bme;
MyMessage msg(CHILD_ID, V_TEMP);
bool metric = true;
float temp;

void setup()  
{ 
	metric = getControllerConfig().isMetric;
}


void loop()
{
	// ... every 5 minutes ...
	
	if (metric)
	{
		temp = bme.readTempC();
	} else 
	{
		temp = bme.readTempF();
	}
	msg.send(temp);
	
	// ... return to sleep ...
}

If I would use a sketch with a condition like this, it would send the temperature in °C to my Home Assistant controller, since it uses the metric system. For you, on the other hand, it would send °F to your imperial HomeSeer setup.

I feel like I gave you the same answer as above, just differently worded. :sweat_smile:
Still, I hope this makes it a little bit clearer for you.

@Karl-S Welcome!

If I understand you correctly, you only care about imperial units. In this case, simply send imperial units from your sensor nodes to HomeSeer or any other controller of your choice. There is no configuration required.

That being said, a controller can "tell" the MySensors network if it uses metric or imperial units, which the gateway will store as a isMetric flag in a ControllerConfig object. Any MySensors node can retrieve the controller config from the gateway, so that you can implement the logic to convert and send measurements in either one or the other unit.

This is helpful if you share sketches publicly in which you want to provide both metric and imperial measurements out of the box, so that nobody who uses your sketch needs to change a thing. But if you write a sketch for yourself, simply ignore the configuration and send imperial measurements.

@keithellis If reloading the integration from within HA can "fix" the issue at least temporarily, I assume that the log should at least give a clue on this. So the best way to troubleshoot such issues may be to activate debug logging in the HA MySensors integrations and consult the logs when the communication stops.

You may also try to remotely read (and store) the WiFi gateway serial output with a library like MyNetDebug.

@Sunseeker According to the Connecting the Radio page, D2 is the default pin for the CE signal for the NRF24. If you'd like to use this pin for I2C, you can free it up by assigning a different pin for the CE signal by adding this line to your sketch:

#define MY_RF24_CE_PIN pin

IIRC, all available pins should work for this purpose (D0, D3, D4). Just pick one and if it doesn't work, use one of the other pins. Please make sure to add that line before #include <MySensors.h>.

Welcome @gav!

The MySensors MQTT gateway subscribes to any topic matching this pattern: mysensors-sub-topic/+/+/+/+/+. The wildcards are (in order) node ID, child sensor ID, command, ack and type (see here for details on the protocol API). Based on that you (or your controller using automations) could publish to any topic with that scheme and the gateway will pick it up. It then constructs a MyMessage object and forwards it to the destination node (the node with the mimic panel, in your case).

For example mysensors-in/10/0/1/0/2 with a payload of 1 will cause the gateway to build a message that is directed to node ID 10 and tells it that there is a new value for its child ID 0, which we would like to set to 1 / true (the payload) and that the message is of type 2 (V_STATUS).

I'm not familiar with OpenHAB, but I assume it provides a way to send custom messages to MySensors. If not, you can always fallback to using "raw" MQTT as shown above.

In any case, make sure that you listen for the incoming message in receive() on the destination node. There is no automation in place for handling incoming messages. You have to make sense of it.

bool isActive;

void receive(const MyMessage &message) {
	if (message.getSensor() == 0 && message.getType() == V_STATUS) {
		isActive = message.getBool();
	}
}

void loop() {
	if (isActive) {
		// Do something
	}
}

Keep the receive() function as short as possible. Check the incoming message and assign variables or set flags here, but do all the time consuming logic inside the loop() to prevent locking up the node, causing recursive loops and such.

Note that the node cannot be put into sleep when it is expected to listen for incoming messages.

Hope this gives you an idea on how to handle such tasks using MySensors.

The EU has developed a new tax payment portal for imports called Import One-Stop Shop (IOSS) for orders below 150 EUR together with the new regulations. Non-EU sellers who sell to EU citizens can use this to simplify the process and charge the correct VAT upfront in the store. The seller and the shipping company have to include an IOSS-related ID visible on the package for the customs office to check. If everything is documented correctly, the local post office should neither charge VAT nor a hefty service fee from you. That's the theory at least.

By now, many of the big trading platforms should have implemented IOSS. I know that AliExpress does for sure and most, if not all, sellers can make use of it - both of my two orders since July were VAT-included and Deutsche Post didn't charge me anything. I don't know how eBay handles that - I think they have no system in place, so that it is up to every single seller to use IOSS or let you deal with the customs. PCBway and JLCPCB do use IOSS, too. I'm not sure about LCSC yet.

But yeah, it is a silly regulation that can make small orders from overseas unreasonably pricey. Over here in Germany, we have some exceptions at least. Import tax (19%) is only due if it is worth 1 EUR or more, so it is only collected if the total merchandise value is 5,24 EUR or more. Deutsche Post / DHL charges another 6 EUR on top of that only if they have to collect the taxes from you. This leads to stupid situations where you can buy something for 5 EUR and have to pay only 5 EUR, but a purchase of 6 EUR can cost you 13,14 EUR including all the fees. :face_with_rolling_eyes:

Edit: On the upside, let's appreciate how straightforward it finally got to buy stuff from overseas that is above the old import sales tax exemption limit (22 EUR usually), because it get's shipped directly to you without any delays. Until recently, the customs office held my parcels hostage and sent me a letter to let me know they have something for me to pick up. So I always had to drive 25 km with the printed out invoice - sometimes waiting up to half an hour in the queue - and open the package there just to pay a few euros.

@Giovanni-Chiva I was certain they merged the multitransport feature into the 2.4 dev branch early on. I was wrong about that. I'm sorry. At least you were able to find the right branch from there on.

Not sure though why you are having issues combining NRF24 and RS485. Unfortunately, I don't own any RS485 modules to make my own tests. Maybe try using a different pin for RS485 DE?

Has this combination been tested by anyone else before?

@Giovanni-Chiva You need the development branch (2.4.0-alpha) for multitransport. 2.3.2, which you are using, doesn't support that. Download here: https://github.com/mysensors/MySensors/tree/development

IIRC, they are not recommended for new designs for at least a few years now. But you can still buy plenty of NRF24L01 ICs from Mouser or LCSC as of today.

CDEbyte still stocks various modules with NRF24 in their stores (see CDSENET, Cojxu and CDEBYTE - they all belong to the same company), but it seems like they are gradually drifting towards replacing it with the SI24R1 IC which are then labeled as the E01C series, as opposed to E01 for the NRF24. I don't own any of the E01C modules, but I'd assume that they still work better than the average unspecified Chinese NRF24 clone from eBay.

What would you recommend for new projects?

NRF5 maybe? They are fully fledged ARM-based SoCs with the NRF24-compatible transceiver included, but note that they are more difficult to work with than the good old Arduino + NRF24 combo. You'll need a compatible programmer, may need additional programming knowledge and I don't know if there are any through hole modules with pins available.

Look for the E73 series from CDEbyte. At least the NRF52832 is rather well supported by MySensors.

There are a couple of threads in the forum to get you going with NRF5, like the NRF5 beginners guide or the NRF5 platform overview. I also wrote a short guide how I got my first E73 to work using an STM32 as a Black Magic Probe.

If you're looking for replacement transceivers to use with ATmegas, look for RFM69 / RFM9x (LoRa). They have a potentially much higher range than NRF24 due to the lower radio frequencies they use, but need a little more effort to set up, notably because you have to manually solder an antenna to them.

I designed an infographic about the commonly used RFM modules by HopeRF a while ago if you need an overview.

@Jeff-Willecke said in Switched to the add-on and now some sensors aren't accepted:

With the new build I used the Add-on integration [...]

By that you mean that you configured MySensors via the web interface?

Your assumption that it is a version issue seems correct, but you can't fix it by specifying a version in YAML when you configured the integration via the GUI.

Could it be that you forgot to adjust the MySensors version during setup? If so, delete it and create a new one. (I don't think you can make changes to existing MySensors integrations (yet))

child_id 8 already exists in children of node 0, cannot add child [...]

That's nothing to worry about. Those warning appear every time you boot up a node that has been presented to Home Assistant before already. It's helpful in situation where you accidentally assign a sensor / child ID twice to different data types or re-assign a previously existing node ID to a completely new node.

@cnerone When you're logged into your Home Assistant instance, click "Configuration" in the sidebar, then "Integration" on the top of that page. Then click the big blue "+ Add Integration" button in the lower right corner and type MySensors in the searchbar that pops up.

@skom Welcome! You're doing nothing wrong.

It looks like some changes in the 3.0.0 release of the ESP6266 core that came out a few days ago is breaking most if not all MySensors example sketches for boards included in that package.

I don't know what is causing this. It seems to be related to the PSTR macro - maybe someone with better understanding of this should have a look at it.

As a workaround, you can downgrad the ESP8266 core from 3.0.0 to 2.7.4 in the Arduino boards manager and it should compile just fine.

@anderBAKE When a node to node communication fails, MySensors will automatically fall back to the default route via the node's parent, so that ultimately the gateway can try to reach the destination node. I'm not sure if you can change that behaviour without touching the library code. But if you don't mind, a small change in MyTransport.cpp should do the trick.

Change the following starting on line 548...

if (destination > GATEWAY_ADDRESS && destination < BROADCAST_ADDRESS) {
	// node2node traffic: assume node is in vincinity. If transmission fails, hand over to parent
	if (transportSendWrite(destination, message)) {
		TRANSPORT_DEBUG(PSTR("TSF:RTE:N2N OK\n"));
		return true;
	}
	TRANSPORT_DEBUG(PSTR("!TSF:RTE:N2N FAIL\n"));
}

to the following...

if (destination > GATEWAY_ADDRESS && destination < BROADCAST_ADDRESS) {
	// node2node traffic
	if (transportSendWrite(destination, message)) {
		TRANSPORT_DEBUG(PSTR("TSF:RTE:N2N OK\n"));
		return true;
	} else {
		TRANSPORT_DEBUG(PSTR("!TSF:RTE:N2N FAIL\n"));
		return false;
	}
}

This will drop out of the transportRouteMessage() function returning false to the send() function if the N2N communication failed.

Note that, after this change, the node will not fall back to the default transport route anymore.

Maybe this could be made an optional feature by introducing something like #define MY_DISABLE_N2N_FALLBACK to MyConfig.h?

The availability of inexpensive commercial products surely is a factor for less interest in DIY solutions like MySensors. Chinese companies are flooding another market once again. Just look at Xiaomi's Aqara and Mijia range of products and their compatible clones. They offer at least a dozen of different sensors and actors in neat little enclosures with either ZigBee or BLE connectivity, many of which are commonly available for much less than 10 USD a piece in sales.

In this view I get frequently asked by friends and relatives why I keep "wasting" so much time building my own devices when I could just buy some like they do and integrate them into Home Assistant or HomeKit with the flick of a switch.

I always respond to them that - apart from privacy and reliability concerns against devices with a forced internet connection, as has already been mentioned by some of you - I actually enjoy the whole process from prototyping electronics to managing a home server. It's a hobby and I learn new things through it. Three years ago, I could barely read basic circuit diagrams - here I am, comfortably soldering self-designed all-SMD PCBs, enjoying programming so much that I branched out into other areas and started developing web apps. I can at least attempt to repair faulty electronics - and have been successful at times - instead of throwing them away and wasting resources.

The whole DIY process forces me to think about my requirements and constraints. To think about what I actually need instead of what I want or could buy to fill a hole.

MySensors is fantastic for someone like me. It is fairly accessible with commonly available components, with the option for much more powerful hardware, if needed. Wireless communication can be remarkably reliable. Other than ESP-based devices, MySensors nodes can be incredibly energy efficient for battery use. It's not polluting my WiFi, nor invading my privacy through cloud services. And although you might say it has gotten quieter in the forum, there's still always someone around to help if you're stuck. It's just that MySensors is strictly DIY, as @monte pointed out. You can't just buy a commercial device, upload a MySensors sketch to it and be done.

That's probably not the answer to the question where everyone went, but rather why not many new come in. Maybe it's a hindrance for new users these days? Because the "DIY aspect", that's now often obsolete, was just a necessary evil for many? Or, as my friends ask, why waste your time with that?

I guess you either have to have a specific mindset and interest to pick this up as a hobby with some dedication, or your requirements are so specific that no commercial product suits them, so that the pressure to DIY is high enough to bring yourself to do so. If not, the big home automation youtubers may show you the convenient way to quick satisfaction.

Regarding antivirus. I'd say no, you don't need antivirus software on Linux. To my best knowledge, viruses and malware for Linux are still very, very rare, due to the Linux desktop / end user market share being tiny. No big malware campaign would specifically target Linux users, since the potential targets shrink from something like a 90% Windows userbase to like 1% Linux users. Unless you install software from shady repositories (think pirated software) or are directly targeted (as in they're specifically after your stuff, not someones), the risk of getting a virus should be pretty low. Follow best practices like avoid loging in as root / super user, compare checksums, think twice before granting programs elevated privileges, install updates regularly, etc.

Linux seems to be rather well protected against threats anyway. Almost all network equipment runs on some sort of Linux. Most webservers are running a Linux. Maybe I'm wrong, but I bet most of them don't deploy a dedicated anti virus software, other than maybe for file or mail servers, to protect Windows clients.

Wikipedia keeps a list of known Linux malware and points out that "few, if any are in the wild, and most have been rendered obsolete by Linux updates or were never a threat".

On Windows, I'd say you're generally good if you use the Defender / Windows Security that comes with it. It provides more or less the same protection against threats as the big name commercial products and doesn't come with tons of bloatware, AI-based voodoo, invasive DLL injections into other software and stuff or accompanying browser extensions, which unnecessarily increase the system's attack surface.

I guess it's worth mentioning, that antivirus software can be harmful, too. Security software isn't safer or more bug-free than other software. And since many antivirus suites integrate deeply into the OS, malware targeting antivirus software has an easy job infecting the system.

Independently from the chosen OS, the best protection is to keep it and all software up-to-date so that known vulnerabilities can be closed or at least mitigated as soon as possible.