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

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

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

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

Some additional remarks: From "outside", afaik deconz behaves to a large extent similar like a hue bridge (e.g. also allowing Adroid apps lie HUE Essentials to connect), so besides FHEM also other Controller software might be able to integrate it.

Some vendors of the ZigBee stuff I've integrated (or at least tested): Xiaomi (sensors are ok, but keep away from relay stuff), Müller Licht, Ledvance, tradfri, various "chinese no name" (e.g. sold by Lidl and/or Ali express (almost all working!)), Sonoff (We-"something", not satisfied in all cases).

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

Use this syntax instead:

#define SN "GatewayESP8266OTA_v3"
#define SV "1.01"
[...]
sendSketchInfo(SN, SV);

@pikim said in RPi gateway options:

I thought the W5100 must have its own SPI bus.

That seems to be true for AVR at least.
I'd been taking about sharing SPI on node side, e.g. for common use for Radio (nRF24) and MCP4341.

I'm unsure at what level of experience you are with MySensors in general. Assuming you beeing complete noob wanting to start with RS485, I'd highly recommend to just start with a simple serial gw - built using an ordinary Nano and RS485 modules. As soon as this works, you may choose how to adding any other kind of complexity, either on the RS485 side (by usage of CAN transceivers) or be it switching over to STM32, later adding LAN modules...
Doing things step by step most likly will lead to faster progress in the end (imo).

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

@pikim said in RPi gateway options:

The ATmega324PB would be perfect imo, as it offers 2 SPIs, 2 USARTs and 2 I2Cs. Unfortunately Arduino supports only one of each type - that makes things complicated again.

I'm not sure wheather this assumption is right. Where comes this info from?

I've already worked with STM32, so that wouldn't be a problem. [...] And I'm afraid that the STM32 is not so well supported as the AVR or a SAMD21.

I just have one other's users report wrt. to STM32 in mind, stating he got relatively big binaries for "easy" sketches and a need to get the right versions of libraries and STM32 board definitions. Didn't sound like fun, so I never went for anything other than AVR...
Nevertheless it's possible to get that up and running as well, but for a start I'd highly recommend to use "common ground".

See also the short write up here: https://wiki.fhem.de/wiki/MySensors_Starter_Guide#STM32

@pikim said in RPi gateway options:

Where can I find informations about that gateway? Which MCU it uses and how things are connected?

See announcement here: https://forum.mysensors.org/post/105364. Afaik this will run on any mcu, also ATMega32 based.

https://www.openhardware.io/view/776/STM32-Ethernet-RS485-MySensors-Gate could also be used for a universal gateway, but it's nearly impossible to get the according MCU at the moment.

If you don't already have experience with STM32 based boards, do not start with these. They really are a good base, but may require some fiddeling around to find apropriate libraries, the bootloader up and running and so on.

I'd advice to choose an ordinary Arduino Nano as a first GW, and then you might either go for a Pro Micro (ATMega32U based, "Leonardo") to get a second hardware-serial interface for RS485 transport layer or then give STM32 a chance (opt for "Maple" version, as some Blue Pill versions have wrong resistors soldered).
Note: Pro Micro requires some tweaks to get e.g. the MySensors bootlogo visible...

@pikim said in RPi gateway options:

Or is it preferable to have a dedicated gateway?

Imo it's highly recommended to use a dedicated WG. This way you get a better separation of Hardware (your Pi acting as a server) and the GW functionality. Once the later is running, you may use it with any other hardware (I myself started with a Pi als server platform, but then decided to go for x64 architecture, especially to get rid of the SD card), or try new forms of Gateway (there's a "multi-transceiver-option upcoming" somewhen in the future) . Just replace a rather simple piece of hardware and the DEF in FHEM and there you go...

Might be wrong, but that kind of check seems to be what's called SOH. Most likely jumping in the code in https://github.com/mysensors/MySensors/blob/development/hal/transport/RS485/MyTransportRS485.cpp#L129 may be a good starting point.

@hypnosiss Hi there, glad to hear someone is developing code for venetian blind covers :+1: .
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.

How about Rhasspy?
That's kind of successor to snips and uses the same (hermes) protocol (MQTT).

For just some "regular" commands to any home automation system just something starting with Pi 3B+ should have enough power to do that.

In my setup (HP T620 as headless x86 server) this runs beside FHEM and deconz on my central machine and receives audio input by mobile phone app (ESP32 satellites are possible as well) allowing full control to all my blinds, lights, ...

@Yveaux said in Wake-up by interrupt doesn't work:

You should not sleep a node that must be responsive to incoming messages.

As smartSleep is used, this might work, but requires the controller software to also support the feature. Additionally, using ACK-request (in case the RF connection isn't reliable) might be a good idea.

@TonicCorvid
Some additional remarks:

• if the node is not battery powered, I'd recommend to use a "non blocking loop" instead of "sleep" or "wait". See the "SLEEP_MODE" - false tree in pulse water meter sketch as a reference how to implement this. Note: this only is needed in case you want some kind of regular reporting (e.g. for a heartbeat message). So just looping and checking pir state (and switching light off after some periode of time) might be closer to what you want to achieve - and easier to program.
• in case it's battery powered and your controller supports the smartSleep feature, imo using that feature instead of wait() is recommended.
• nut sure, but using long wait() periodes in battery powered nodes might dramatically shorten battery life.

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

Is there any specific reason for using 2.2 and not either 2.3 or even 2.4 (development tree)?
Afaik, there's been especially some changes around the RFM drivers, so giving newer versions a try might be a good idea :wink: .

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