How to start working with Homegear?

[jirm]

I am a newbie at Homegear (installation running for only 3 days), so I expect a lot of patience and complacency on your part for my clumsiness and ignorance.
Also my apologies for my bad English that is not my native language and I can not express myself as I would like.
Indicate that I am not a software programmer either, so my notions about it are very very basic.
First of all express my admiration for the good work done at Homegear. I think it’s a wonderful work.
The installation I have is a simple zero rpi with module cc11001 on the gpio hat (v 0.3) created by @Pmayer, which I take this opportunity to expressly thank you for. This rpi will only execute homegear in a dedicated way and for the moment it will only control my trv Max! in a total of 8 radiator valves of what my heating system consists.
The installation of homegear raspbyan was fast and without problems installing the image that exists for the purpose with raspbyan in read-only mode. The basic configuration of homegear for the RF gateway was also relatively easy and the pairing of the trv in homegear was also quite fast once I took the appropriate steps.
All helped a lot with what has already been published in these forums.
Let’s get to the point …
I have many doubts of all kinds, but I will start with what now worries me most.
First: I am in the phase of creating an automation that allows me to send the desired modes and temperatures to “all” devices with a simple call.
My intention is to try to use mqtt and publish a single command for each change or temperature order, for this I thought it would be convenient to create an automation in node-blue so that receiving the node-blue command is responsible for sending the order to all devices and check if necessary that the device accepted the change but failed to create anything functional.
I have started by creating these two test automations in node-blue:
flowautotest1.txt (7,3 KB) flowautotest2.txt (9,0 KB)

As expected they don’t work as they should.
The problem is that if I send more than 1 or 2 devices simultaneously there is a “congestion” in the execution of the radio orders and therefore Homegear fails to send the order to the device, or maybe rather the device does not send the confirmation of the execution of the change of mode or temperature.
Log errors appear (Warning: You 're sendig too many packets at once !. Sending MAX! packets takes a looong time!) makes me suspect that it is a problem of make a congestion with too many simultaneous orders of RF to process and sending to trv devices.
I have tried to modulate the send with delay nodes but without enough success and normally only 3 or 4 of the TRVs change state and both in the flow (flowtest1) for auto_mode and in the flow for change to manual mode (flowtest2).
It is evident that my node-blue flows will be badly raised and proppperly created, but I also wonder if there is any other more correct approach (by means of scriptting, etc …) to achieve my objective with Hemgear.

Any suggestions will be welcome and surely a great help.

Next days…much more doubts to comming…

Thank you

[job]

Hi @jirm,

i use something similar to reset my thermostats every night to auto-mode. I have about 15 radiator thermostats and 10 wall thermostats on my RPi 3B+. As you see, every delay just sends about two thermostat commands. (Each delay is 5 seconds.) I am using Homematic, not Max!, so your mileage may vary.

You also could move your php function (convert to float) in front of the passthroughs, this would reduce the number of nodes.

[jirm]

Thank you so much for your reply @job.

With your help I have recreated the node-blue flows and now at least they work.
But I still have problems executing them since usually some of the TRVs refuse to execute the order.

Mansetall.txt (7,9 KB) Autosetall.txt (5,6 KB)

I have been several checks and trying to isolate the cause of the error, but I still have not been able to find out why and I continue testing.

When the fault is processed, an error of the type “communication with device has been disturbed …” usually appears on the homegear UI console.
Reviewing the logs (setting debug level 6) I can not see clear communication problems with the devices, but when errors appear show some messages about the device (trv) in question does not respond (not reply).
Sometimes, after a few minutes, homegear seems to be able to execute the order on the device (I suppose that due to the retries queue it has established) and in others the change is not made in any way on that device.
Comment that if after receiving the error, if I send the command again but specifically to that device, it responds normally without problems to that order or any other query that you can make (over mqtt, rpc from HA, etc.), by what seems evident that the problem that occurs is of very short duration.

What I have tried:

• I had linked homegear in HA (Home Assistant) and I have unlinked it to prevent the interaction and avoid a possible cause of interference in the execution of orders that could overlap.

• I have checked the RF coverage and it does not seem to be a cause at least in a clear way that can prove intermittent communication failures on the devices, but at this moment cannot be totally discarded.

• I have increased the delay times in node-blue flows, and although it seems to improve the success rate, it fails to eliminate the errors completely.

At the moment I do not have many more ideas to diagnose the problem, and at the moment I continue doing more tests to verify in a more effective way that RF coverage is not the cause, since the situation of the RF transmitter of the rpi is not the best for reach all trv.
There are some trvs that report an RSSI between 75 and 85, which is clearly not the best.

Any suggestions will be very helpful.

Thank you.

[sathya]

Hi @jirm,

reliably setting multiple wake on radio devices at once is a nightmare… But it should be possible to set it reliable enough. Could you post the log starting with the trigger until the error occurs? Maybe that helps identifying what could be changed.

Cheers,

Sathya