Different local BUS addresses

[gsek78]

Different local BUS addresses

[FredBlo]

Hi @gsek78 ,

The connector works (for now) only on the private riser (i.e. the bus on which the gateway is directly connected).
The WHERE with #4 is actually common to all devices split on multiple local buses (not only for lights).

I also have a F422 but it is configured in 'physical separation' (meaning I am able to have 2 power supplies but all addresses are shared across the IN & OUT of the F422, acting both as a private riser).
I guess your are working in expansion mode ? (requiring more than 160 addresses, correct ?)

If you configure your flow as you did, I think you will be able to send commands, but not to monitor these lights (when a BUS command is received, the connector will not be triggered).

I could add such parameter but requires many changes to all nodes (& I am not able to test this on my system :-( ).

Are your F422 there to extend to >160 addresses or for other purposes ?

[gsek78]

Hi @FredBlo ,

Thank you for your prompt reply.

Yes , my F422’s works on “Logic expansion” operating mode - configurator MOD = 2 .
In any case my installation is under the hardware limit ( with virtual configurator 175 address , I think )
I think that the electrician who made the installation chose this mode mainly because was easiest to configure ( it’s not necessary to set up the “A”/"PL" numbers on F422 for each bus , just to set the mode and the bus number ) .
Luckily he put different ambients in each bus , the address are consequential with no overlaps , so theoretically I can physically change the cables and reconfigure the F422’s in “Physical expansion” operating mode - configurator MOD = 1 .

Yes , you are right ! As I configured it I can send the commands on BUS 2 but I don’t see any feedback from the actuator. 😏

I tried your module because I would like to integrate MyHome to HomeAssitant and seem quite easy to do it passing through Node-RED integration .
I couldn’t find any direct OpenWebNet-HomeAssitant integration to do it but I found a very interesting project that go DIRECTLY on the SCS bus ( https://www.home-assistant.io/integrations/scsgate/ ) , is really interesting for many reasons:

• cost ( you don’t need a BTicino Gateway ) but a cheaper hardware
• more control ( theoreticcaly using a low-level language direct on the SCS bus you have more possibilities, eg. you can also send a signal status to commands without having a physical actuator changing it’s status light )
• stable communication ( before your project I tried also another nodered project https://github.com/eziologico/MyHome-Node-Red and I had problem of missing messages and gateway disconnections )

Unluckily , at the moment, also SCSGate development have a problem with “multiple buses” ( is unsupported )

I spoked and met the developer of the hardware , Guido, http://guidopic.altervista.org/alter/eibscsgt.html ( sorry for Italian - here TRANSLATED with Google Translate ) he made a wonderful reverse engineering job of SCS protocol and also a good hardware and software work. I am in contact with him and maybe he can improve the “multiple buses” . I am confident, we will see !
Maybe you can also study an integration on Node-RED ...

Meanwhile… did you think you will add the multiple bus frame to your OpenWebNet project ? I can try it for you on my myHome 😉

Let me know if ( and when in case ) you are interested to develop this feature.

At the moment the most plausible option is to reconfigure my installation and go to “Physical expansion” operating mode

Many thanks !

[FredBlo]

Hi,

I could update the node to include on the node a BUS specification (private riser, BUS 1, BUS 2,...) but I think it will actually not do something really better in comparison to what you achieved now. (it will only remove the error Node-RED detects because it expects 'numbers' in A/PL, but it has no other side-effect)

Based on my understanding of the way logic expansion works, a BUS is capable of sending commands to another BUS but will not receive the response (since BUS is isolated in this mode).
To test if this is correct, you could, with your test flow, collect what's monitored on the bus (i.e. output of 'MH200N Monitor' node) when :

1. press 'ON' linked to 'Light B0_A1_PL1'
   -> Result is *1*1*11## and then *1*1*11## a second time ?
2. press 'ON' linked to 'Light B2_A5_PL1'
   -> do you see *1*1*51#4#02## or *1*1*51## or... one time or more ?

On the other hand, if you do not need >175 addresses (you're right it was not 160 :-) ), I do not really see the added value of isolating your BUSes (but I do not pretend I know all about this). In this mode you cannot have a 'normal' push button (i.e. H/L4652/2) to operate an actuator on another BUS. If your ranges are configured to allowed this, I would advice to work in 'physical expansion' (MOD=1) to have kind of

• Private Riser 1.x -> 3.x
• BUS 1 4.x -> 7.x
• BUS 2 8.x -> 11.x

Let me know :-)

[FredBlo]

Hi @gsek78,

Have you been able to test and collect the BUS messages ?

[gsek78]

Turn ON , light 11 , ( command sent via OpenWebNet , NO Hardware BUTTON )
*1*1*11##
Turn OFF , light 11 , ( command sent via OpenWebNet , NO Hardware BUTTON)
*1*0*11##

Turn ON , light 11 , local hardware button on BUS 0
*1*1000#1*11##
*1*1*11##
Turn OFF , light 11 , local hardware button on BUS 0
*1*1000#0*11##
*1*0*11##

Turn ON , light A 5 PL 1 , local hardware button on BUS 2
*1*1*51#4#02##
Turn OFF , light A 5 PL 1 , local hardware button on BUS 2
*1*0*51#4#02##

*1*1*11##
5/6/2021, 19:37:13node: BUS Monitormsg.payload : string[9]
*1*0*11##
5/6/2021, 19:37:17node: BUS Monitormsg.payload : string[14]
*1*1000#1*11##
5/6/2021, 19:37:17node: BUS Monitormsg.payload : string[9]
*1*1*11##
5/6/2021, 19:37:19node: BUS Monitormsg.payload : string[14]
*1*1000#0*11##
5/6/2021, 19:37:19node: BUS Monitormsg.payload : string[9]
*1*0*11##
5/6/2021, 19:37:43node: BUS Monitormsg.payload : string[14]
*1*1*51#4#02##
5/6/2021, 19:37:44node: BUS Monitormsg.payload : string[14]
*1*0*51#4#02##

Let me know if you want to made other test ;)

thanks !

( I discover that copy and paste here is not working fine ... see attached text to read better the text )

TestCommands.txt

[FredBlo]

Hi @gsek78 ,

Thanks for tests :-)

Based on your feedback, it seems the commands are passing on to the main riser too, which is kind of good news.
In your previous post, I understood light state did not get updated at node's level. Is this correct ?
i.e. when turning a light ON/OFF using a physical button, do you see a node's status update in the one linked to BUS 2 ?

such as

PS : all 'texts' in GitHub are in 'markdown language'. Since * is a special character used for formatting content, it causes strange results with OpenWebNet commands... :-/ When you have such commands, simply enclose it between `. More info on syntax to be found here. I updated your post so you can see it better :-)

[gsek78]

Hi @FredBlo ,

thank you for your answer , I made another test ... the status seem working .
I don't know why but ( if I remember well ) when I tried before was not like this .. maybe I made a mistake in the first trials , sorry !

In any case ... see attached video : https://user-images.githubusercontent.com/85118979/121254732-e7918000-c8aa-11eb-8104-04f2a8e91d52.mp4

I made a simple Node-red project to make the trials , it's not yet finishihed ( the function " TO HomeAssitant " to update the light status in HomeAssitant is not yet developped ) , I attached it here , have a look . flows.zip

Let me know if you will roll out the "Multi-BUS" feature .

Thanks and Ciao !

[FredBlo]

Hi again @gsek78,

The flow as I see it should work nice.
I would maybe consider using a switcher (or a function which manages multiple outputs) to avoid one payload sent to all your light points at every HomeAssisant triggered flow. This is not a problem if you have a few lights you want to manage this way (& this is actually kind of developer's thoughts :-) )

About module evolution, since bus info is passed by to and from the gateway, looks quite simple to adapt.
I had a bit of a check on the light node (I need to update this on light, shutter and scenario nodes; thermo does not have that management level, must reside on private riser), would look something like :

[FredBlo]

Hi @gsek78 ,

I just published an intermediate v2.2.1 which includes BUS management (for lights, shutters & scenario).

I tested to ensure it does not cause any regression when working on private riser. Can you test it in local bus config mode on your side ?

:-)

[gsek78]

Hi @FredBlo ,

sorry for my long non-attendance period ! I was busy with my family and my work .

Yes ! I will try it on my house and give you a feedback .
Just a small note . I am not sure that " thermo does not have that management level, must reside on private riser " , I have some HC4692 also on local bus ( BUS 1 and BUS 2 ) . I will check how they work and let you know ;)

Ciao and thanks for your work !

[FredBlo]

Hi @gsek78 ,

Normally, based on my understanding (of documentation of the OpenWebNet for thermo regulation and F422), these commands (WHO=4) should be managed by the F422 to travel in the two directions without any processing.
Addresses for thermo regulation are not extendable (>99) the same way it is made for automation, they also don't share the same bus addresses (A/PL).
So it should work...

Anyway, let me know ;-)

[gsek78]

HI @FredBlo

You are right !
It's all working fine , also the thermoregulation on different bus ;)
In the next days I will try shutters and scenario but I suppose that is all OK , in case of problem I will write you

Many thanks for your job !

[FredBlo]

Hi @gsek78 ,
You're welcome !
Thanks for testing & feedback

Enjoy