Posts made by rejoe2

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

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

@skywatch said in Solar/battery powering:

@zboblamont said in Solar/battery powering:

@rejoe2 Anti-freeze.

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

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

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

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

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

@skywatch It really might depend, how "northern" the respective area is, but at least here in Germany, the used liquids imo are well tested and don't cause much trouble also in (rare) frost or snow conditions.
(@all: Sorry for one more OT comment).

@skywatch said in Solar/battery powering:

But yes - I always wondered why they didn't water cool the panels and use that hot water for the house hot water system or swimming pool. I suppose that would increase production and installation costs and complexity significantly as well as add more points of failure.

In fact, theres some few companies offering "hybrid panels", see e.g. https://www.todoensolar.com/300w-ecovolt-hybrid-solar-panel or https://dualsun.com/en/product/hybrid-panel-spring/ (don't have experience with neither of them).
Imo complexity isn't that much higher than with "conventional" solar panels for heating systems (liquid based, as known for much longer than the use of electrical PV systems in private environments). It's just the PV aspect added, which itself isn't highly complex, too. In fact, one needs bigger water (or other liquid) tanks to store the "conventionally harvested" part or the solar energy. If you don't already have this part of the installation up and running, the question is, if this makes sense at all or if just using electrical energy to heat (much less) (heating) water is more cost efficient.
(But this isn't really MySensors related, as 300+W will in most cases not be necessary to drive one or some more nodes...)

youtube really seams to tear "everyone" to "fast and easy solutions". I personally really hate that IoT stuff talking to the www without asking and therefore try to avoid whatever can't be flashed with own firmware for "offline" use.
Atm. I'm fiddling around vith voice control via Rhasspy. Really impressive project, btw. (I'm not to deep into all the details on that, but controlling my lights, shutters or media stuff works really great, even without any online service provided by any of the big players; just a service with relatively small resouŕce footprint on a dual-core server built ages ago!).

@monte said in Where did everyone go?:

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

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

@NeverDie said in Where did everyone go?:

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

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

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

@monte said in Where did everyone go?:

It feels like people come to mysensors, make relay node, temperature sensor

If one just wants to have a temperature (or humidity) sensor or a relay, buying ZigBee or BT or ESP826x-based stuff is cheap and easy, no need to fiddle around with voltage regulators, fake nRF24L+, capacitor sizes and so on. So most people just beeing interested in quick solutions will not even care about these simple sensors.

and then go forward for more complex solutions to never come back.

Imo, MySensors still is a very good solution if you have the need for more complex or "clever" solutions. Choice is not to big, if you are looking for solutions with wired or LoRa nodes, and scripting more complex "rules" for Tasmota or ESPEasy seems not to be very common to build somehow autonomous subsystems.
Btw.: node2node communication in MySensors is not well explained as well. So also in the MySensors ecosystem most users are used to rely on some sort of central system to do logics as soon as more than one node is involved.

@frits: Thx for analyzing this issue. Atm I honestly don't have no clue how to deal with this change in the FHEM module code. When analyzing ECHO, there's a check weather send info is identical to what's been sent.
So the only way out seems to be less exact and also let be 0 the same as "nothing" (Perl doesn't use NULL).

@karlheinz2000 Perhaps, we could ad a small if statement at the end of line 760 to treat 0 as "nothing" or undef?

or $_->{payload} ne $msg->{payload} if $msg->{payload}

Deleting the entire line might cause problems...

Thx, so this seems not to be the reason behind that.
Sth. else: If possible, it could be a good idea to add some more content to the thread title (ECHO in 2.3.2 changes message content)?

@karlheinz2000
Which type of radio you are using? There might be a difference between nRF24 and other (RFM-based?) transceivers. So if possible, also make a test with 2.3.2 and nRF24.
Problem may be related to the change from soft ACK to ECHO (https://github.com/mysensors/MySensors/releases).

@mrhutchinsonmn At RS485, it's obligatory to assign NodeIDs within your sketch.

Question: Is your gateway connected to some controller software?
Afaik, MySensors won't work propperly without, this is what you experience as problems with ID request and transport layer reset. Though there are options to get around that, I'd strongly recommend to involve one.

@Adam-Slowik Afaik, 0xFFFFFFFFF isn't garbage but the request to the controller to assign a ChildID. So most likely, you have to create a special handler for such a request (comparable to what nRF24 or RFM drivers most likely do) or make sure to assign a ChildID in every node's sketch manually (similar to RS485 transport layer usage).

@OliverDog You may have a look at https://github.com/sidoh/esp8266_milight_hub. It uses basically the same hardware as a normal MySensors Wifi-GW and is able to receive and send (most) of the MiLight-Codes. I'm using the MQTT interface offered by the hub not only to translate MiLight-V5-protocol type of remote codes not only to control V4-protocol type of rgbw bulbs (which seems to be close to your request), but also to set shutter levels or even control my mpd... Obviously, this nees some additional coding on controller side (FHEM in my case).

@projectMarvin He might have meant https://www.candlesmarthome.com.

There might be several other cloud-free open-source solutions for home automation. I personally use FHEM which "since ever" has been designed to run cloud-free and allow local control to virtually everything. (downside is: most likely as most (all?) other controller software offering a lot of options and allowing to control everything, you have to learn the underlaying language or at least a lot of specific commands/script instructions). Despite that, if you absolutely desire to involve one of the big internet players, it's possible to also add voice control options (to some extend also locally afaik; I' more focused on automation to overcome the needs for active user interaction).

Beside that: +1 to the statements of @projectMarvin .

Recently came across this here: https://github.com/saghonfly/shrdzm/wiki. Seems to be an ESPNOW-based solution (MQTT-GW is also available).
Did no testing on that at all (I'm more tending to use wires/RS485 for homebrew stuff ), but if you are insisting in using these nasty Espressif-mcu's, this might be intresting...

@jocke4u said in Parallel Gateways:

In what sense do you consider RPi-Ethernet-GW to be more tricky than Arduino-Ethernet-GW?

See https://forum.mysensors.org/topic/11145/started-with-mysensors-and-about-to-give-up-some-feedback for a lot of people reporting about running into problems. Imo it doesn't make much sense fiddling around with a very complex base (Pi) when using a very simple base (arduino@serial or LAN-gateway) is possible...
Just my2ct.

Wrt. the other stuff, I completly agree with @mfalkvidd's approach; at first sight it seemed you were looking for a drop-in replacement. But as soon, as you want to update nodes also, different channel is a very good idea.

@jocke4u In which aspects do you expect problems?
Imo it's just a question how your controller deals with that. E.g. in FHEM, one can switch around IO devices without problems, and a second GW will just "see" all messages beeing send. Note: Using both to controll anything most likely isn't a good idea.
I assume, you already know the PI-GW-variants to be more tricky than ordinary serial WiFi or ethernet gateways?
If you are about to build up new hardware, you may have a look at https://forum.mysensors.org/topic/11135/something-s-cooking-in-the-mysensors-labs/10 as well and e.g. prepare the hardware to use different type of transports as well in the future?

Good to her you found that point .
Imo you'd better change also your receive functions to not react on "ack" messages (via "else" prior to message.type-comparison).

@FullMetal Pls add also code from node 4.

In general:

• if you want also info from node 5 to be sent to your controller/gateway, you have to add a second (normal) send command.
• wrt. to how node 4 reacts on the messages, you may better use sth. like a toggle logic.

@FullMetal Imo, you have to specify all send-settings in one line, e.g. like this:

send(buttonMsg.setDestination(MY_SISTER_NODE_ID).setSensor(CHILD_ID_RESET).set( button[i] ? "1" : "0"));

@ibibiuooui said in Water Meter Pulse Sensor:

!TSM:INIT:TSP FAIL

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

Starting with MySensors in the 2.0.0-beta days with nRF24 (and no technical or IT educational background), I completely agree with a lot of the things already mentionned here.
It was a lot easier then and most of the transceivers (even the most likely couterfeied ones) worked with some caps added. But I saw a lot of people struggling when trying out themselfes, be it counterfied chips, struggling with what the controller sw (FHEM in my case) does or (often) - using the Arduino framework to get combined nodes.
So I started doing some wiki work with focus on FHEM (MySensors Starter Guide), collecting also the experience from some other users there.

As atm some new users became interested especially in wired solutions, I was very happy to see the PJON integration making good progress. Imo this is a very good and easy approach, as no additional hardware is required. This makes this transport layer imo the best choice to get into the basics on MySensors and it's interaction with the controller sw as well. Choice for controller in most cases might already been done when joining the community here, so imo this could really help to "join this train here" more easy, as testing doesn't need much wiring or additional hardware.

The only disadvantage is the lack of RF. So starting with PJON as "learning level transport layer" and adding then RFMxx als wireless option might be considered as primary recommendation for the first steps towards wireless then?

@iamtheghost I'm using FHEM as controller software in combination with MySensors (serial/USB, now all RS485 protocol using CAN transceivers) along with ZWave (USB-Dongle), HomeMatic-BidCoS (old technology, not -IP version, several Gateways, one of them @USB), Zigbee (deconz, also using an USB dongle) and some other MQTT-speaking stuff. Server's x86 based running on Debian (I dislike SD cards), and using a Raspberry Pi shouldn't be an issue, it's the most common platform for FHEM.

MySensors is as seamlessly integrated, as well as the other stuff is. But don't expect FHEM to be easily confgured. But when the learning curve flatens and you're familiar with it, it offers a lot of options to get whatever thing done...

@fdlou147 According to my personal experience, I'd recommend to split up Gateway and Node funktionality and use two seperate mcu's.

Wrt. to the code itself: you only set up a debouncer on one of the pins (finally: Pin 5), as you always redefine the same "flags" over and over again. Perhaps have a look at this imo excellent multi relay/button sketch by korttoma here. This one should be not to hard to adopt to your needs (still, I'd recommend two mcu's).

@rvendrame Apart from the distance question I'm completely with you. Nevertheless I'll try to get that working It's already coded, so why not test it out? If it's not working or not used by anyone: no problem. I just wanted to avoid setting some kind of standard that might be somehow wrong.

@zrom69
No real Problem in turning off debug output, at least in 2.3.1 this worked:

// Enable debug prints to serial monitor
//#define MY_DEBUG
//#define MY_DEBUG_LOCAL

#define SN "Zwischenkeller"
#define SV "0.2"

// Enable RS485 transport layer
#define MY_RS485

// Define this to enables DE-pin management on defined pin
#define MY_RS485_DE_PIN 2

// Set RS485 baud rate to use
#define MY_RS485_BAUD_RATE 19200 //57600 //38400 //9600
#define MY_RS485_SOH_COUNT 1
#define MY_RS485_HWSERIAL Serial
#define MY_SPLASH_SCREEN_DISABLED

You may even swap around debugging output from hardware serial to software serial, see basic structure from this post in FHEM forum (german, but most is code).

@BearWithBeard: Wrt. to nRF I'm absolutely with you. But nRF isn't the only transport layer available, e.g. I'm more or less exculisvely using RS485. In such a setup, also no repeater is needed for (theoretical) distances up to 1.200m.
So beside the fact, this isn't really needed in alsmost any case, I'd really appreciate having a working common approach to the problem.
Additionally: that might include allowing much larger chunks of data sent on each transmission on suitable transport layers at RS485, CAN (got stuck, see here) or (maybe) PJON to get a better overhead/payload ratio.

@Guillermo-Schimmel It indeed should not be to difficult, but still there are some questions to be addressed:

• Is there any common standard (e.g. mark start and end of transmissions with keywords like "START" or "END") in stream messages (other than OTA)?
• How about multi stream options (different ChildIDs).

Afaik the ony sample transfer code ist this one. Using that as a base, I recently built a (not yet tested) version that most likely will be part of the FHEM integration, so I'd really appreciate some common approach to that topic to not propose a somehow "strange" implementation.
But no answer on that question until now.

Having a deeper look at resistor values is always a good idea.
Indeed, optimal values depend on a lot of parameters. You might find a helpful tool for getting the best values for your setup here: http://www.alciro.org/tools/RS-485/RS485-resistor-termination-calculator.jsp

I've been looking around a bit, but beside the example Perl script provided by @thomas1412 and the STREAM type usage in the OTA feature, there seems not to exist any working solution using really the stream type message structure. But this is more or less receiving only on the node side afai understood.

As I'm about to do some renovation work on the FHEM integration (also written in Perl), I'd be interested in some guidelines about the best way to transfer e.g. jpeg data as stream from node side.
The sample sketch @thomas1412 provided uses not stream type, but V_VAR1 (data) and V_VAR2 (signalizing start and end).

I'd be happy if someone could provide a sample sketch using the newer (?) stream type sending style or a link to the relevant parts in the MySensors codebase...

@Rysiek In general, I don't see any problem in mixing softwareserial and hardwareserial (I did that in the past, too).
Wrt. to sleep: My entire RS485-MySensors-setup consumes ~3W (dependent on relay states), so powering down the arduinos most likely will save some power, yes; but imo that's negilable.
What might happen when powering down: the bus might get blocked, if one of the nodes keeps bus on "high" level. I had some nasty problems wrt to that, so I make sure, there is nothing (slightly) suspective of such behaviour (additionally, I changed the RS485 Modules with CAN ones (MCP2551) - they don't need no DE/RE/interrupt, too and can be used as a drop-in-replacement. The only disadvantage: they are not PIN-compatible when using SOIC-8 variants, so you can't use most of the board designs from openhardware.io).

OK, so thanks for info.

Some additional remarks:

• using a GW also as a sensor node might cause trouble, too. I'd recommend to avoid that (though it's possible, no question). This recommendation is even stronger here, because reading DS18B20 might be blocking for short periods of time (see "conversion time").
• That conversion time may be an additional point to look at at the GW node. Didn't do investiagations on that, but your measurement might not deliever reliable results due to lack of delay.
• In general, I'd also recommend to use non-blocking-loops for all central powered nodes. Putting the nodes 1 and 2 to sleep or let them "delay" for longer periods might also cause trouble. Better start with "dumb" messages (e.g. send a "tripped" message every 30 seconds) to test if your problems are more on the physical communication layer or on the software/firmware side.

@Rysiek As you are using a Pro Micro as a GW, imo the RS485 modules should be connected to Serial1 instead of Serial (which goes to USB).

@Stef9998 said in not understanding Smart Sleep:

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

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

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

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

@Stef9998 said in not understanding Smart Sleep:

After describing my use case, is smartsleep what I need?

I'd say yes, clearly - if your controller is supporting the smartsleep feature.

But to make it more clear: when the sketch uses smartsleep, two type of smartsleep messages will be sent out: one when waking up, the second before going to sleep. Usually, the controller should ONLY send out queued messages when the second is sent. Why? To avoid collissions on the RF layer.
The discussion you cited is the one I had in mind, and afai remember, it highlights a second aspect: usually, smartsleep is the last thing the node "does" before going to sleep. So you are able to switch sth. on in the "receive" function or change variables, but especially changing variables like the time the node will be asleep, will only have any effect when the loop is processed. Means in this case one step later than desired...

@Stef9998 Actually, it only sends the special message "I will go to smartsleep" and no real "heartbeat" message.
All other things are handled in the controller - especially handling the queued messages. In general, imo choosing smart sleep ONLY makes sense, if you want/need OTA support for nodes you can not easily reboot by hand or want to switch, (re-) configure ... and so on at runtime.
In short: details are tricky and you have to thouroughly check what is needed on both sides - controller and node... (I had some interesting discussions here long time ago wrt. to the FHEM integration and changes in sleeptime duration. Perhaps you might search for that - imo, it should be very instructive.
(We ended up using the heartbeat signal to signalize towards the controller that the node is already in the state of listening prior to the "will-go-to-sleep-now" message).

@szymo092 said in Small RS485 network - questions.:

1. Will my network work without controller (only gateway + nodes)?

No. (As always in software: it is possible, but you'd need additional coding...) So basically: MySensors should always be connected to a controller.

1. It is possible to send something from first node to the other one?

Yes. You have to add destination info when sending to another node.
(for code examples on both - not using a controller and node-to-node communication, see the two sketches in https://github.com/rejoe2/SkiStopwatch).

1. If I connect network to the controller it will be possible to set any parameters from this controller?

For sure; this requires some receive() functionality - just the same as node-to-node messages, so see mentionned examples or one of the MySensors-counter-build examples.

1. What can I do first?

Make sure, only two of the RS485 Modules have the 120Ohms resistor and get your controller up and running .

Don't know much about Domoticz, but most likely you just have to set the name (the address?) as third argument whithin present().
Perhaps you find some reusable parts in https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency/blob/master/DallasTemperatureSimple/DallasTemperatureSimple.ino

I've no deep knowledge in these things, but imo the proposal from @tmandel leads in the right direction. Just looping once more (and perhaps having the info that the smartSleep-command has been skipped to avoid unnecessary additional measuring and so on) imo is the cleanest solution to this kind of trouble.

This reminds me on a discussion some time ago which lead to this feature request: https://github.com/mysensors/MySensors/pull/1271
Perhaps you might check out if that would help.

@dzjr said in Best choise for a controller:

I also have FHEM running on a Virtual machine, and to be honest it is not what I am looking for, among other things FHEM does not see the sensor names in the presentation, so this will all have to be set manually, and further I saw that you have to set a lot by hand.

There's an option to derive the reading names from presentation info ("get <name> ReadingsFromComment"), but most likely you will not be satisfied with the result. But for sure, FHEM isn't an easy "mouse-based" system to understand and customize. On the other side it offers any option to do whatever you like within your system.
But anyhow: Thanks for having a look!

@robert Use an array to address all available PINs. As a reference (more complicated, as there are buttons used, too), see @korttoma's example here: https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33.

@monte
OK, so let's concluse: FHEM and HA seem to have at about the same functionality - FHEM amongst others also supports KNX.
It's up to the TE (and whoever may read this in the future) to decide what to prefer - I'll stick to FHEM which I'm now pretty familiar with...

@monte said in Best choise for a controller:

@rejoe2 but is there anything that FHEM supports and HA doesn't?

As I'm not familiar with HA, it's rather hard to give a valid answer to this question. As already mentionned, FHEM is strong in hardware integration, so eg. SOMFY shutters might be an example. In general, FHEM gives the option to run a cloudfree HA system, so the need for external (especially google) software to steer some thermostats rather sounds ridiculous to me - FHEM especially is able to control Z-Wave, EnOcean, MAX and HomeMatic (not "-IP") hardware with just an USB dongle for each of these wireless protocolls; my ZigBee installation just uses some piece of software running on the same server hardware and also an USB dongle.

Also FHEM provides some modules for "easy" configuration of typical HA tasks like shutters control (taking into account a lot of stuff like sunrise/sunset, internal/external temperatures, shading needs, individual's presence...) or heating control. Don't know what HA provides in that direction, though.

Also keep in mind ongoing development in contrary to others (over 70 releases on github this year alone). For example google pulled off "works with nest" API, so many users can't use their thermostats with 3rd party software, but one of HA users made a simple dirty hack which makes it possible to integrate your nest thermostat for now, until google will release their new API for users.

FHEM is also under ongoing development, but follows a different release strategy, it's more like a perpetual beta, so updates can not be counted in "releases". If you install the current debian package with release 5.9 and do an update (from within FHEM), you will get around 2.000 commits applied since the release of 5.9 and still be on feature level 5.9. Additionally to mentionned that: the most of the commits not affecting the core part, which is rather stable.
If you opt for the docker version, you will get an up-to date system just from the first second.

Also HA is written in python which makes it pretty easy to fix any issues or add new features.

Python might be more common than Perl these days, but wrt. to that point there's no further significant difference between the two.

Wrt. to bugfixing and reaction to changes "to the outer world" also an example: When yahoo closed down it's weather service (afaik, they didn't prewarn), it took around 4 weeks until there was a different solution provided - without need to do a lot of changes for those users who used the data within their FHEM installations - they had e.g. just to get a key from darksky and change the data source (but internally the code structure had been rebased to be much more flexible for the future).

@dzjr said in Best choise for a controller:

@rejoe2 I had never looked at FHEM myself, I will certainly do so.

As a server, I also received a tip to use an Intel nuc instead of a Pi.

Have a look at Linux compability first when looking for Intel NUC. My HA system runs on a ThinClient platform from hp. Consumes slightly more than a Pi or newer NUC, but only costs around the same as a new Pi.

Wrt. to what @monte said about Home Assistant: Comparing is not really easy, as one can focus on different things, but most likely FHEM might stand the test, especially if you focus on hardware integration and automation (but to be honest: Perl on which FHEM is based is "special" and seems to be no longer "a la mode").
If you are able to read German, you can find some infos on FHEM compared to OpenHAB and IOBroker here - there's also some few remarks from users with HASS experience (most of them highlight the shiny UI of HASS, and there are also some FHEM users going for FHEM for automation tasks and hardware interfacing and HASS as UI).

@dzjr You may have a look at FHEM. At least all of your present hardware will be supported, and it's really a stable base that might run on any rasberry base (despite imo that's not a good choice for any HA solution, but that's different story).

The same ChildID most likely isn't the cause for the missed relay commands, but the "wait" instructions. IMO the code should be changed to a "non blocking loop". Search the web for that keywords or have al look at https://www.mysensors.org/build/pulse_water as an example within the MySensors framework.

@sebex said in Advise - Building air quality sensors/network:

Regarding the 1 gateway, you mean stay away from home automation at first?

Imo, MySensors without HA Controller doesn't make sense or even will not work (without additional tricks). But to get familiar with a specific piece of hardware (e.g. a sensor type like the DS18B20), it's much easier to use the standard arduino sketch examples included in virtually every "library" without additional MySensors stuff first and add that as a second step (or first try if it's working on the PIN you plan, (e.g. PINs able for direct interrupt use are limited and so on).
So you also know, the hardware is working - that unfortunately can also happen...

@sebex At least some answers to your questions:

• As Nano and Uno use the same processor, there's no big difference between the two, besides the fact Nano's just USB powered...
• when talking about environmental data, you'd perhaps also like to have a look at BME680; it doesn't deliver CO2 directly, but the delivered restults ale partly calculated on this.
• Most newer (I2C-) sensors seem to work at 3.3V internally, so when powered directly at 3.3V, you might be able to avoid losses due to a voltage regulation
• DS18B20 Modules sometimes come with a resistor, so you'll have to desolder that in case you want to use more than one on the 1-wire bus; "naked" sensors might be more suitable, e.g. if you want them to be mounted closed to a metal tube to measure water temps => depends on your needs.
• ZigBee and MySensors are completely different worlds. (Apart from RS485) MySensors itself is capable of building a mesh network.
• In general, MySensors can be used with any meassuring equipment as soon as there exists an arduino library for the hardware - the rest ist just "packing" the measured values in a MySensors-compatible format for data exchange with te controller. Searching the web for CO2+arduino+sensor gives at least some results. Better ask for experience with a specific sensor and avoid starting "multiple" questions threads like you did here.

@trs-80 Imo it's not as easy as comparing (or even just counting) some fancy pictures to really make a judge on the "most integrations" issue .
As a FHEM-user (without OpenHAB experience thouhg), I'd state there's at least three or four big systems missing (on the picture collection): HomeMatic / HomeMatic-IP, 1-Wire (it's more than DS18B20 ) and EnOcean. All of them are supported by FHEM, and additionally a lot of "special" stuff (like RS485 protocolls and many others). To get an impression, the commandref is a good starting point). Additionally, there exist a lot more "innofficial" modules for whatever purpose...
So in fact, I've seen quite a few people leaving FHEM in the past (it requires quite some familiarizon) and coming back to it, also from OpenHAB for it's flexibility. Also the level of comfort may vary from integration to integration.
So I'd state, there's not THE nor perfect answer to the question which controller supports the highes number of integrations

@electrik: You may not know about FHEM, but afaik it's also a very good candidate for the champions-title on supporting "the highest number" of devices...
(Velo17 already has FHEM on his list )

From FHEM side of view, you may use any of the Types MySensors offers, most likely presenting one or more S_POWER Children fit closest.

To get "better" reading names, I'd give the "get <device> ReadingsFromComments" function a try and add a comment to the sketches present() function (Cell1, ..., Solar, Battery...).

It's a bit hard to explain. If you have some experience with DS18x20 type of sensors, you may get an idea looking at the code here (or make some experienents with it): https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency/blob/master/DallasTemperatureSimple/DallasTemperatureSimple.ino

Asking the controller at startup: issue a request, see https://www.mysensors.org/download/sensor_api_20#requesting-data, imo you should as for V_STATUS.

Then your controller should respond, the response is handled by the receive()-function (=no action needed), but to get this to work, your node should not sleep (you sketch seems to be incomplete wrt. that).
But you should first switch off everyhing to have it in a defined state and avoid loading values from the EEPROM.

Wrt. to regular status info: If that's necessary, you should try to use a so called "non blocking loop", use g**gle or similar for that. Imo, it's not necessary to update the value as it doesn't change. Better use the heartbeat funcionality instead (dependend on your controller).

Based on the great sketch korttoma posted here, the following could work:

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_NRF24

#define SN "RelayButtonArray"
#define SV "1.0"

#include <MySensors.h>
#include <SPI.h>
#include <Bounce2.h>
#define RELAY_ON 0                      // switch around for ACTIVE LOW / ACTIVE HIGH relay
#define RELAY_OFF 1
//

#define noRelays 4                     //2-4
const int relayPin[] = {14, 15, 16, 17};       //  switch around pins to your desire
const int buttonPin[] = {6, 7, 4, 5};   //  switch around pins to your desire

class Relay             // relay class, store all relevant data (equivalent to struct)
{
  public:
    int buttonPin;                   // physical pin number of button
    int relayPin;             // physical pin number of relay
    boolean relayState;               // relay status (also stored in EEPROM)
};

Relay Relays[noRelays];
Bounce debouncer[noRelays];
MyMessage msg[noRelays];

/*
  void before() {
  for (int sensor=1, pin=RELAY_1; sensor<=NUMBER_OF_RELAYS;sensor++, pin++) {
    // Then set relay pins in output mode
    pinMode(pin, OUTPUT);
    // Set relay to last known state (using eeprom storage)
        digitalWrite(pin, RELAY_OFF); //digitalWrite(pin, loadState(sensor)?RELAY_ON:RELAY_OFF);
  }
  }*/

void setup() {
  wait(100);
  // Initialize Relays with corresponding buttons
  for (int i = 0; i < noRelays; i++) {
    Relays[i].buttonPin = buttonPin[i];              // assign physical pins
    Relays[i].relayPin = relayPin[i];
    msg[i].sensor = i;                                   // initialize messages
    msg[i].type = V_LIGHT;
    pinMode(Relays[i].buttonPin, INPUT_PULLUP);
    wait(100);
    pinMode(Relays[i].relayPin, OUTPUT);
    //Relays[i].relayState = loadState(i);                               // retrieve last values from EEPROM
	// digitalWrite(Relays[i].relayPin, Relays[i].relayState ? RELAY_ON : RELAY_OFF); // and set relays accordingly
    //send(msg[i].set(Relays[i].relayState ? true : false));                 // make controller aware of last status
    wait(50);
    debouncer[i] = Bounce();                        // initialize debouncer
    debouncer[i].attach(buttonPin[i]);
    debouncer[i].interval(30);
    wait(50);
  }
}

void presentation()
{
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo(SN, SV);

  wait(100);

  for (int i = 0; i < noRelays; i++)
    present(i, S_LIGHT);                               // present sensor to gateway
    request(i, V_LIGHT); //...not sure if this is the right syntax
  wait(100);
}


void loop()
{
  for (byte i = 0; i < noRelays; i++) {
    if (debouncer[i].update()) {
      
      int value = debouncer[i].read();
      
      if ( value == LOW) {
        Relays[i].relayState = !Relays[i].relayState;
        digitalWrite(Relays[i].relayPin, Relays[i].relayState ? RELAY_ON : RELAY_OFF);
        send(msg[i].set(Relays[i].relayState ? true : false));
        // save sensor state in EEPROM (location == sensor number)
        //saveState( i, Relays[i].relayState );

      }

    }
  }
  //wait(20);
}

void receive(const MyMessage &message) {
  if (message.type == V_LIGHT) {
    if (message.sensor < noRelays) {          // check if message is valid for relays..... previous line  [[[ if (message.sensor <=noRelays){ ]]]
      Relays[message.sensor].relayState = message.getBool();
      digitalWrite(Relays[message.sensor].relayPin, Relays[message.sensor].relayState ? RELAY_ON : RELAY_OFF); // and set relays accordingly
      //saveState( message.sensor, Relays[message.sensor].relayState ); // save sensor state in EEPROM (location == sensor number)
    }
  }
  wait(20);
}

I tried to just comment out things not needed, so you might find it easier to understand the differences between loading from EEPROM and requesting the state from controller side.

@apl2017 Yes, also for RS485 variant you'll need a gateway. Only the communication between the gateway and the other nodes is handled over RS485, connected to a second (typically software) serial interface (for remote nodes, you may just use the hardware serial interface to connect the RS485 transceiver, if you do not need debug output; but imo this option is not recommended for beginners).

@bereska said in Water Meter Pulse Sensor:

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

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

...just let the node count some pulses (your code states: FALLING). So just pull the counter PIN (here: D3) to ground several times.

@bereska said in Water Meter Pulse Sensor:

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

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

You are using the same ChildID's for relays and tripped/door states. Imo this is messing things up, so e.g. use 11+12 for tripped values.
Remark: If you are looking for a good example on using arrays for that kind of tasks, see korttomas work here: https://forum.mysensors.org/post/51488

As you already did some differnenciation wrt. to the ChildID, this seemed not to be to far beyond your actual knowledge. Sth. like

if (incomingOutlet == 0 && (message.type == V_LIGHT || message.type == V_DIMMER))

should do the trick .
Wrt. to arrays to avoid all the repeatings in the code, it's not that easy. Assuming, the send-codes to be longint type of data, sth. like

const uint16_t RF_CODES[NUMBER_OF_PLUGS] = {
{4072574,4072566},
{4072572,4072564},
{4072570,4072562},
{1386894,1386886},
{1386892,1386884},
{1386890,1386882}
};

might easen addressing sendCode to sth. like

RF_CODES[incomingOutlet-1][incomingLightState]

Note: This is completely untested...
Within MySensors, array coding is not really part of the default sketches, so you should have a look at the normal arduino examples.

Two short remarks:

• last if-branch in receive() additionally needs clarification to only be meant for ChildID 0; this should "cure" the problem you are working on.
• For the general structure of your code imo it would help much to use arrays to store all the info.

@GieBek

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

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

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

@pepson I'd suggest you make a test with the "simple" variant of the sketches. Then we could lateron discuss how to deal with an array containing the hardcoded addresses.
Pls. make also a test with the hardcoded version. Afai remember, it will print the needed array to serial, as long as #define PRINT_ARRAY isn't commented.

@pepson That's not necessary: The sketch reads the bus to get all the necessary info and will just send whatever is found.

If you want a "hardcoded version", you'd have to addopt the sketch for something in between these variants: if you use an array for the 1-wire addresses like https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency/blob/master/Dallas_Addresses_Array_Solution/Dallas_Addresses_Array_Solution.ino does, just built the comment char-array based on that info.

@pepson said in About DS18B20 onewire.:

@mfalkvidd
OK but also must add defined description to all address. But how add also description?

Don't know, if that really works, because I never tested it since my controller sw supports comments: https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency/blob/master/DallasTemperatureSimple/DallasTemperatureSimple.ino

@uwek Special-Debug only gives some more info about the sketch, so this most likely will not help.
Wrt to ACK, I'm not familiar how the MySensors lib handles that internally, but FHEM will keep all the messages seperate from each other.
I also have little experience with RFM modules; for nRF interrupt handling is not necessary, but most likely, this is the exception. Anyhow: It seems to work to some extend, so I'd not bet to much on this as the root cause of your problems.

So ok, you want to learn the hard way ...
If the mcu is an ESP8266 also on the node's side, forget about PIN2/3 beeing special, this applies to standard ATMega32P. But perhaps you'd have to define a different interrupt pin for the RFM.
Frankly spoken, imo it's easier to start off with a more default setup...

If there's no ACK, messages will be resent, so your log excerpt from FHEM may be to short (repetition should start with +1 sec, times will be prolonged lateron).

Remarks on your code:

• better keep hands off from PINs 2+3 and reserve them for interrupt-based tasks (might be here input Pin 3 for your button, but debounce2() and using differen PIN is ok also)
• RFM69: Better connect interrupt (PIN2)?
• RSSI may need #define MY_SIGNAL_REPORT_ENABLED

@uwek said in Update Issues from Master request(...):

@rejoe2
Hmm, i'm using this line numbers. Line 179?? haha, gues i'm looking into something wrong

Sorry, that was 3 lines to much, but most likely you noticed the principle . But why looking at some github repo? Most recent code is always in svn: https://svn.fhem.de/trac/browser/trunk/fhem/

@uwek wrt to ACK: If a node sends with ack, it will be resend as long as the parent (eg. the GW) has indicated reception; no need to queue on the arduino side. On FHEM side, the IO module enqueues also the ACK messages. So you may test the use of ACK on controller side also?
To see, what was sent from FHEM side, you can set your IO device to verbose 5.
Sounds a little as your IO has transmission problems, because I'm almost sure, the module code itself will not loose any information on it's path throughout FHEM.
Wait() in combination with a specific answer expected is also new to me, but sounds interesting.

Wrt. RSSI, afai remember, the RSSI feature also has to be activated on the Arduino side. If you've done so, this also points to transmission problems at the gw hardware - I'd bet, the node never "hears" the request.

Wrt. to line 113: V_WATT will be transated in a readingname "powerx" with "x" beeing the child ID; same with V_STATUS => statusx. This is line 179 resp. 158. As this is the original authors code, I'm also not sure wheter that setup makes to much sense, but on the other hand - besides some more aestetical aspects - don't see the neccessity to put much effort in that; you effectively are not limited to "1", it's just the GUI that's missleading here...

Without the "wait()" statement, messages from and to the GW may interferre with each other. You may get around that by using Ack's in the requests (most likely "1" instead of "0" as the third argument). But as this is just initializing code (?), imo the wait() isn't really an issue.

The other thing with FHEM adding one reading named powerx for each of the relais is a result of line 113 in the device-module. To be honest, I'm not quite sure if that makes much sense, but this is the behaviour since ages...

Imo all these messages are addressed to the GW. See https://www.mysensors.org/build/parser. Destination "0" stands for the gateway.
The log parser may also help to understand what is behind your other post here. The repeater node imo just acts as kind of sniffer and puts everything that's received to serial out, regardless if repeater functionality is necessay or not.

@rejoe2 I also send a heartbeat-request with MYSController to the GW and the GW was responding.
I send via MYSController 0;255;3;0;18; and received 0;255;3;0;14; and all the other presentation messages.

Ok, there's one possible additional thing you might test in FHEM: Most likely the heartbeat request is published under childID 0, not as in MYSController as broadcast (255). For testing, you might add

childID => 255, 

somewhere in the get function (sendClientMessage(), at around line 356).
For all other Nodes, also childID 0 seems not to be an issue.

Pretty strange symptoms.
Do you have the option to connect the GW via USB to check if you get the heartbeat messages there?

Then we could try to dig deeper into that, if you get this message type over serial also. I'm pretty sure other type of GW's work at least closer to your expectations: I myself have different serial GW's and there's no issue in FHEM to request heartbeats from controller side.
Most likely also WLAN-GW's work as expected in this aspect, as FHEM-user Sidey, who has contributed the code for checking, if a GW is still connected, used heartbeat-requests for that purpose, and he's using ESP8266-based GW's.
So most likely this problem is limited to Ethernet GW's.

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

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

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

@tmandel

@rejoe2 Thank you for your effort with patching the FHEM module.

You're wellcome!

Wrt your patch: To get that into the mysensors repo, you'll have to use the (very painfull, but due to copyright reasons necessary) regular github mechanisms to get registered as kind of mysensors developer. Then you can send it as a pull request against the MySensors repo. As you use a new flag (?), you'll have to add some short decription wrt that also.
I'm not very familiar with all these processes, but in case you need help wrt that you may also contact me via FHEM forum for assistance.

Btw: Good job!

update: above mentionned module has been updated and now should load without trouble

@tmandel said in disable/cancel smartSleep while sleep countdown is running:

@rejoe2
would it be possible to send out all queued messages if the controllers receives a heartbeat from the node? Maybe this should be a good solution, event if last POST_SLEEP_MESSAGE got lost. We dont have to invent new message types.

I could test your code on my development FHEM system.

Using heartbeat imo is a good idea. This usually isn't used in smartSleeping nodes (smartsleep signals themselves renew alive state), so we could easily use that as a "deliever what you have" request.
Additionally, I have also changed other parts of the logic a bit: in case any information is sent out while node is alive will initiate also sending the queue, so e.g. any kind of requesting data would have the same result as heartbeat (or even a "by-accident at the right time" sending trial)...

So here's a completely untested version. "Should" work, but no guarantee:
https://github.com/rejoe2/FHEM/blob/master/10_MYSENSORS_DEVICE.pm

@jlaraujo said in disable/cancel smartSleep while sleep countdown is running:

Regarding the post sleep message, i believe that the current controllers programming (certainly Domoticz and FHEM it seems) should accept the POST_SLEEP_MESSAGE as an indication that the node is ready to receive messages.

Some additional remarks on the FHEM code:
Indeed, as soon as the POST_SLEEP_MESSAGE is received, all new messages will be sent out without enqueueing (additionally, also requesting data will lead to direct sending of all new info until PRE_SLEEP_MESSAGE is received + a waiting time has elapsed).
But: direct sending out enqueued messages after reption of POST_SLEEP has turned out to be not a good idea, as already mentionned. This is why imo this message as such isn't a good criteria to decide about sending out enqueued data.
Perhaps it could be a good idea to start sending also enqueued info before the PRE_SLEEP, but only in rare cases we know the node to wait for info from controller side (e.g. after request time or status info messages).
Other option could be to define an individual waiting period per node after PRE_SLEEP to start sending (new Attribute).

@tmandel : Please let me know if either way would help. In any case, I'd need someone to do testing in case of code changes in that part. Programming timer functions not killing fhem in some rare cases turnded out to be a tricky job .
In any case, it could be a way around your troubles to request most recent info before going to sleep.

Wow, very impressive code change!
Imo sending the post-sleep notification should at least lead to the node beeing indicated as "awoken" in FHEM. But as already mentionned, all new messages towards the nodes need a new pre-sleep-notification.
So you at first will have to send this type of message; if this message is lost, this will also lead to an increasing nr. of retained messages when "sending" out new info (the queue will be extended, but nothing really send out).

To create a new status like "awoken and ready to receive" might be a good idea; to change the FHEM-code for support of that kind of feature would not be a big issue (at least I hope so ).