Persistent connection not working with multiple commands

[FerX]

Persistent connection not working with multiple commands

[FredBlo]

Hi @FerX ,

The nodes have actually 2 parts :

• monitoring all BUS activity : this one has to remain permanently connected. When connection drops, it is re-established (and it is automatically refreshed every xx seconds, which is the 'Kee alive' param
• sending commands on the BUS : every command sent will initiate its own gateway connection, send commands, wait for responses (if any) and then disconnect at the end. Switching to a queuing mechanism for sent commands (i.e. having all nodes' calls centralized and sent by managing a maximum rate) would be hell of a revamp work on this :-(... it would also make the system slower to react for gateways supporting multiple client's connections, therefore requiring kind of a multiplexer system to be added, with multiple queues.

When developing this, I did overload the gateway (which then timed out to respond for a while), overloaded the BUS (which makes the whole MyHome system react very slow), but I never crashed a gateway :-)

My questions to you :

• when you talk about 'crash', what happens ? The gateway stop responding to external calls (=time out), is not activated (i.e. scenario not working on the BUS either),... ?
• have you tried to configure the MH200 to allow connection without password when connecting from node-RED (i.e. by setting your server's IP as white-listed in Bticino config) ? This is made in TiMH200
  

Fyi :
I personally first had a MH200 scenario manager on my BUS. It was my only RJ45 capable device then.
When adding new devices (such as BMSW1003 or BMSW1005) on the MyHome system, I was not able to configure them (virtually I mean) using PC software. The old 'Virtual Configurator' did not recognize new devices... and the new 'MyHOME_Suite' refused to connect using MH200 as gateway...
My electrician contacted Bticino which explained MH200 was not an official gateway, it was not supposed to be used as this,...
Gateway function was only supported starting MH200N, MH201 and MH202 (or expensive Web F453). They argued the MH200 hardware was 'too weak' to allow such evolution...
As a result, I added a basic gateway (F455) which is quite cheap and does the job. I also afterwards replaced MH200 by a MH202 because I needed some of the new functions it allowed...
I still have the MH200 but not connected on the BUS. I could reconnect it to make a few tests.

[FerX]

Thanks for the support.
I've added the IP to the whitelist in order to eliminate the login step.
However, I noticed that even if I set the delay time to 1000, the calls are still made simultaneously.
With a function, I am sending an array of commands to MhInject.

const commands = []
const zone = [81,82,83,84,85,86,87,88,89,98]
zone.forEach(z=>commands.push({
    payload:`*#4*${z}*19##`
    }))
return [commands];

How can I make sure that the commands are executed in sequence and not simultaneously? Because since I've implemented these functions, sometimes MH200 doesn't perform its scenarios correctly anymore.

thanks

[FredBlo]

OK, I understand.
Actually the code you provided will build an 'array of msg'.
In node-RED, this means you start many separated flows (1 per msg). The delay defined in the inject node will not apply in such a case since each flow is managed separately.

In order to have multiple commands sent in a single msg, you just need to have the msg.payload to contain the array of commands, such as :

const commands = []
const zone = [81,82,83,84,85,86,87,88,89,98]
zone.forEach(z=>commands.push(
    `*#4*${z}*19##`
    ))

const msg = {};
msg.payload = commands;
return msg;

In this case, the node receives, in a single flow, multiple commands, and is able to manage those accordingly, applying delay between each command

Hope this helps :-)

[FerX]

This solution is wonderful. Thank you.

[FredBlo]

You're welcome :-)