Biomatx integration

[canatella (Damien Merenne)]

Since it seems I’m not the only one with a Biomatx domotic module and using home assistant. I’ll share what I have currently.

I developed a python library for interacting with the module there: GitHub - canatella/pybiomatx: Control BiomatX home automation system

Documentation is a bit lacking as I never thought I’d share this but here is a quick run up.

To connect to your biomatx, you need an RS-485 adapter, either to USB or to Ethernet, the serial python library used to communicate supports both: URL Handlers — pySerial 3.0 documentation. The serial lines should be connected to the module using a twisted pair connected to the two middle pads of an RJ45 connector (if you number the pads from 1 to 8, the 4 and 5 pads, no matter the way you look at the connector as they are the middle ones). The easiest is probably to use
an ethernet cable, cut one side and use the twisted pair that’s connected to the middle pads, most probably the blue/stripped blue one.

I used this serial to ethernet adapter: Industrial RS232/RS485 to Ethernet Converter

Then you can extract the integration into your hass installation and restart home assistant. Go into integrations, add the biomatx integration, configure the device or url according to your adapter.

GitHub - canatella/hass-biomatx: Home assistant integration for Biomatx

Hope this help, I’ll try to monitor this thread for questions as far as time allows.

[JeromeB]

Hello Damien.

I have purchased a similar RS485 to ETH adapter : https://www.waveshare.com/wiki/RS485_TO_ETH_(B)

That should be OK but I’m having a slight issue with the HA integration… The config widget displays no labels… I don’t know exactly what is required…

See attached screenshot.

Can you help ?

[JeromeB]

EDIT : It took me a while to figure this out, but the integration seems to take care of dependencies. Things were not obvious, the pybiomatx library files at GitHub - canatella/pybiomatx: Control BiomatX home automation system refer to versions up to 0.0.7 while the integration code asks for 0.0.8. The proper version is hosted at biomatx · PyPI. I could not figure this out without being a seasoned python dev, so many thanks to Pierre for helping with this.

Ah, never mind, I sort of figured this out reading the biomatx/config_flow.py file.

I am however stuck way earlier in the process… I initially missed the part where your specific pybiomatx library is required. Fine. The library requires python (no idea if it’s installed by default on HA). Additionally you advise using pipx to install your library, but I can’t find how to install that tool under Home Assistant.

I am trying to write a detailed A to Z documentation for people who, like me, are NOT python or HA developers. As is, there are too many missing bricks.
Is python installed under HA ? I think so, but if not, then how to install it ?
How to install pipx ? Their doc specifies Windows, Linux, macOS. I’m running Home Assistant OS 12.1 (I can’t remember the installation specifics, it seems to me it’s a docker image on top of Ubuntu).
How to use pipx to install the pybiomatx library ? (I suppose the library has to be downloaded from Githib before being installed using pipx, and then some file is passed as a parameter to the pipx tool)

*The only python related tool I’m finding in HA is AppDaemon. Which seems like an alternative to pipx somehow. *

Any help or hint would be welcome. Thanks ahead.

[JeromeB]

Not everything is ok, however…

Installing the integration
After reading the code and some trials and errors, we were able to figure out the proper parameters for the integration :

• First line (CONF_DEVICE) is the URL of the bridge (or device reference if using a local USB device). My device does not take rfc2217 (telnet) so I had to use socket. The port and IP address are configured on your ETH/RS485 bridge device of course.
• Second line (CONF_MODULE_COUNT) is the number of BiomatX devices in the setup.
• Third line (CONF_SERIAL_WAIT) remains unclear to us, we left it to 0.
• Fourth line (CONF_ALL_OFF_ADDRESS) is the address of the “All off” scenario in your BiomatX setup (I set mine on scenario 8, since scenarios are always on the same “virtual” module with address 7 that resolves to 7_7, or in short for this assistant just 7).
  

Connection with the server on the bridge device eventually works when hitting “submit”, and we get 60 devices, one for all 50 channels (5 modules) as well as for 10 scenarios (note : I don’t know if it’s 100% correct or a hidden feature, but the official BiomatX doc states that there are only 8 scenarios, so 7_8 and 7_9 might be useless). We also get 60 binary_sensor entities and 50 light entities. At this point we believe the TCP communication between HA and the bridge is all set.

Regarding serial communication
On top of the TCP/IP configuration, we had to set the serial parameters on the bridge device to match what was in the integration and library code. Before that we were getting errors in the log. The only change was with the bit rate, which we had to slow down from 115200 to 19200.

Integration not working yet
At this point, the integration is still not working.

• When starting the integration, the “all off” scenario is not properly being run. Or maybe it is on the integration side, but the modules do not react.
• When trying to change the state of a light entity, nothing happens on the BiomatX side.
• When hitting an actual button, we seem to receive something from the bus which is not properly handled by the integration.

Logs :

Logger: biomatx
Source: runner.py:189
First occurred: 4:47:04 PM (292 occurrences)
Last logged: 7:11:14 PM

    dropping invalid start byte b'\xfe'
    dropping invalid start byte b'\xfc'
    dropping invalid start byte b'\xc5'
    dropping invalid start byte b'\x9f'
    dropping invalid start byte b'\x8f'

We suspect more settings need to be adjusted on the serial side of the bridge, which we think is issuing garbled data to the modules and misinterpreting incoming data. This is only a supposition. Can you provide any guidance ? Do you think of something else ?

Note : we did try switching polarity on the bus by switching the blue/white-blue wires on the bridge (it is apparently a common issue with mixed RS485 devices because the standard is poorly worded to begin with regarding polarity). It did not work any better and previous error messages were not coming in any more, so we reverted to the original wiring and stroke polarity off the list of possible causes.

Extra question for later fown the road : what are the binary_sensor entities for, as they seem to offer no user controls ? How are they supposed to work ? They only show “off” events matching each time the integration was restarted.

EDIT 2024/04/17 :

Hello again,

Not knowing exactly what to do, considering that maybe the issue is caused by the apparent lack of rfc2217 support from my ETH to RS485 bridge, I did order another device from the same manufacturer : https://www.waveshare.com/wiki/RS485_TO_ETH

• The original device (https://www.waveshare.com/wiki/RS485_TO_ETH_(B)) did not explicitly support rfc2217.
• This new device does, if I’m reading its feature list properly.

On the other hand the new device does not support modbus, no idea if that’s used by the BiomatX modules.

Note that despite being sold by the same manufacturer, these devices come with completely different web GUIs and Windows-based config tools, so I suspect they’re not running the same software.

I’m apparently facing the very same problems, that is :

• Unable to connect when trying to build an rfc2217:// URL :

serial.serialutil.SerialException: Remote does not seem to support RFC2217 or BINARY mode [we-BINARY:False(INACTIVE), we-RFC2217:False(REQUESTED)]

• Invalid data when trying to build a socket:// URL :

Logger: biomatx
Source: runner.py:189
First occurred: 5:35:54 PM (32 occurrences)
Last logged: 5:35:58 PM

    dropping invalid start byte b'l'
    dropping invalid start byte b','
    dropping invalid start byte b'+'
    dropping invalid start byte b'm'
    dropping invalid start byte b'-'

I don’t really know what else to do, except maybe try yet another device. Damien, can you provide any hint here ? Am I missing something obvious ? Thanks ahead.

MORE STUFF I TRIED :

• Set CONF_SERIAL_WAIT to 0.5 instead of 0 (after reading __init__.py)
• Force serial port to 19200, 9600 and 4800 bps

[canatella (Damien Merenne)]

Hello,

Thanks for looking at all this. The documentation is indeed lacking, but I never thought I’d share this.

The serial conf wait stuff was used at some point to configure the time to wait between sending commands at the biomatx module so that it could process them. I apparently hard coded that at 0.2 second and never removed the configuration parameter, but it’s related to sending command to the biomatx so probably not related to your issue.

With first device, where you saw these:

Logger: biomatx
Source: runner.py:189
First occurred: 4:47:04 PM (292 occurrences)
Last logged: 7:11:14 PM

    dropping invalid start byte b'\xfe'
    dropping invalid start byte b'\xfc'
    dropping invalid start byte b'\xc5'
    dropping invalid start byte b'\x9f'
    dropping invalid start byte b'\x8f'

It’s the integration code looking for some bytes that are sent by the module at the start of an event, so I think the communication is working on your side, but the protocol between your biomatx modules might be different ?

Just to make sure, did you connect to the port at the bottom right that’s used for inter-module connection ? The one with the label rj 45 comminucation ? To me it’s connected at the end of the chain on the left one.

If it’s still not working, then we would need to try to reverse engineer the protocol on your side. What would be interesting is to look at the logs, press a switch on your side then look again at those dropping invalid start byte that were received, and post that together with the address that the switch is bound to. Note that some data should appear when pressing the switch, and again some new one when releasing the switch. Do that with a few different switches so that we can analyze the difference
between them, each time writing the bytes corresponding to a press and release and the switch’s address.

Also do you have the module to control it with a web browser ?

PS: I enabled the email notification, I hopefully will be more reactive…

[JeromeB]

Hello Damien,

Many thanks for your time.

One of the possible conclusions from our observations is that indeed the protocol used between my modules is slightly different. I’ll provide info below to try to figure this out.

Before looking at my BiomatX setup and its specifics, a few observations/questions :

• We have tried different baud rates on the serial side to try and rule out the possibility that the data is garbled because of a speed mismatch between the RS485 bridge and the BiomatX modules. I see your code sets the speed at 19200 (I think it would only work using and rfc2217:// url, as it is my understanding that the client can then push serial parameters to the bridge, which is not possible using the raw connexion with a socket:// url). Is this speed something you are sure about ? I never found anything in the BiomatX documentation.
• I tried reversing polarity on the bus side using the connectors on the bridge, as RS485 is poorly worded in that regard (if you look around, you will find out that not all manufacturers implement polarity the same way on the RS485 A and B ports of their devices).

But yeah, as you stated, it looks a lot like things are properly configured.

On to my BiomatX setup…

Basic setup

• I have 5 light modules, model 2110.
• I do NOT own the MEWS Lt module for direct PC connection.
• The 5 light modules are daisy chained together using short UTP cables, using the ports you outlined and as in the BiomatX user guide (page 9).
• Addresses are set from 1 to 5 (BiomatX front panel LEDs), so technically modules 0 to 4.

Module 1 (address 0)
Left UTP goes to the RS485 bridge
Right UTP goes to module 2 (address 1)

Some intermediate module
Need I say more ?

Module 5 (address 4)

About push buttons and addresses

Of high interest : I do not use the “Anabus” for push buttons on my modules (where push buttons share a 5-wires bus and have manually configured addresses using dip switches boards in the wall boxes containing each button, user guide page 8). Instead each push button is wired to one of the individual digital inputs at the bottom left of the modules (user guide page 7).

However, I do not believe that this impacts the addressing protocol used on the RS485 bus, here’s why :

• Using individual digital inputs for each module means you don’t even need to connect the modules together (e.g. dedicated input 3 on a given module triggers relay 3 on the same module). Although the BiomatX guide implicitly states that it’s possible (user guide page 11) (presumably to use scenarios and/or the MEWS Lt module). I only connected them for the purpose of using the RS485 bridge and the HA integration.
• However, when you connect modules using dedicated inputs together, two modules using the same address will act as mirror of one another : anything triggered on one (either using the dedicated input or the local button on the module itself) is triggered on the other (this behavior is explicitly documented in the BiomatX guide, page 7, and I was able to confrm it easily). This means that any action on a module, is passed on the other modules through the RS485 bus, even if the system does not use the Anabus for its buttons.
• Also, as per the BiomatX documentation, if using Anabus buttons, the address of the modules on the RS485 bus and the address of the button boards on the Anabus have to match one another. The information received from the Anabus is most likely just passed to all modules on the RS485 bus.

This leads me to think that the same basic message “Module 1, button 5” is passed on the RS485 bus whether the user is

• A. pushing local button 5 on module 1,
• B. pushing a distant push button connected to input 5 on module 1,
• C. pushing a distant push button connected on address 1,5 on the Anabus (using the dip switches on the in-wall address board)

From that first reasoning and based on the existence of the MEWS Lt module that would also send messages to the RS485 bus, I would then deduce that if a Home Assistant integration (or any other piece of code for that matter) sends the same messages on the RS485 bus, it should not matter if the system uses the Anabus or dedicated inputs to connect its in-wall push buttons.

(I would go as far as to think that you could conceivably run in a form of hybrid setup, using both the Anabus AND dedicated inputs. Unfortunately I do not have address board to test this theory.)

Of course this is all an assumption I’m making based on my observations.

Maybe the messages ARE different, maybe the 2-bytes payload does contain some information as to the source of the action (local button / dedicated input button / Anabus button). In this case, the messages received from triggering the dedicated inputs on my modules are not those expected by your code, which is expecting messages indicating buttons triggered on the Anabus. Also it’s possible that if no BiomatX module uses the Anabus, then the messages received from the integration and referring to Anabus buttons are simply ignored.

I still believe my initial line of thinking is correct and we are seeing something caused by some other side effect in the addressing protocol or in the RS485/IP interface, for these additional reasons :

• I have noticed one of my light circuits improperly turning on based on unrelated actions on the integration side (meaning some improperly-formatted information sent by the RS485 bridge still happens to trigger my module).
• I have noticed some action on the in-wall buttons being interpreted by the integration as a push on a button from a non-existent module address 6 (the integration then explciitly drops this action because it was configured for 5 modules, not 7).

And now for the logs…

I reinstalled the initial RS485 bridge and did some experiments…

Comparison of using a local button (on a module) and a remote push button (wired through dedicated input) :

TRIGERRING ON THEN OFF PUSH BUTTON ON DEDICATED INPUT 8, MODULE 1 (ADDRESS 0.7)
13:11:51.587 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:11:51.588 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:11:51.760 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:11:51.760 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'
13:11:56.159 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:11:56.159 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:11:56.382 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:11:56.383 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'

TRIGERRING ON THEN OFF LOCAL BUTTON 8, MODULE 1 (ADDRESS 0.7)
13:12:05.336 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:12:05.336 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:12:05.588 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:12:05.589 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'
13:12:10.415 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:12:10.415 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:12:10.649 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:12:10.649 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'

All local buttons for module 1 :

TRIGERRING ON THEN OFF LOCAL BUTTON 1, MODULE 1 (ADDRESS 0.0)
13:03:59.185 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:03:59.185 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:03:59.378 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:03:59.379 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'
13:04:03.547 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:03.548 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:04:03.762 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:03.762 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'

TRIGERRING ON THEN OFF LOCAL BUTTON 2, MODULE 1 (ADDRESS 0.1)
13:04:08.609 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:08.609 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:04:08.812 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:08.813 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'
13:04:13.082 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:13.082 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:04:13.286 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:13.286 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'

TRIGERRING ON THEN OFF LOCAL BUTTON 3, MODULE 1 (ADDRESS 0.2)
13:04:17.037 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:17.037 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:04:17.232 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:17.232 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'
13:04:20.922 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:20.923 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:04:21.108 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:21.108 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'

TRIGERRING ON THEN OFF LOCAL BUTTON 4, MODULE 1 (ADDRESS 0.3)
13:04:24.748 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:24.749 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:04:24.922 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:24.923 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'
13:04:28.643 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:28.644 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:04:28.849 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:28.849 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'

TRIGERRING ON THEN OFF LOCAL BUTTON 5, MODULE 1 (ADDRESS 0.4)
13:04:32.609 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:32.609 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x9f'
13:04:32.814 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:32.814 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x8f'
13:04:36.425 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:36.425 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x9f'
13:04:36.609 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:36.610 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x8f'

TRIGERRING ON THEN OFF LOCAL BUTTON 6, MODULE 1 (ADDRESS 0.5)
13:04:40.181 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:40.182 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x9f'
13:04:40.396 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:40.397 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x8f'
13:04:44.029 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:44.029 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x9f'
13:04:44.212 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:44.212 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x8f'

TRIGERRING ON THEN OFF LOCAL BUTTON 7, MODULE 1 (ADDRESS 0.6)
13:04:47.833 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:47.833 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:04:47.998 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:47.998 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'
13:04:51.658 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:51.659 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:04:51.833 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:04:51.834 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'

TRIGERRING ON THEN OFF LOCAL BUTTON 8, MODULE 1 (ADDRESS 0.7)
13:04:55.415 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:55.415 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:04:55.600 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:55.600 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'
13:04:59.370 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:59.371 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfe'
13:04:59.546 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:04:59.546 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xfc'

TRIGERRING ON THEN OFF LOCAL BUTTON 9, MODULE 1 (ADDRESS 0.8)
13:05:03.246 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:05:03.247 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xcf'
13:05:03.421 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:05:03.421 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc7'
13:05:06.992 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:05:06.992 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xcf'
13:05:07.177 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc5'
13:05:07.177 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc7'

TRIGERRING ON THEN OFF LOCAL BUTTON 10, MODULE 1 (ADDRESS 0.9)
13:05:10.729 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:05:10.729 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xcf'
13:05:10.893 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:05:10.893 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc7'
13:05:14.734 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:05:14.734 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xcf'
13:05:14.918 WARNING (MainThread) [biomatx] dropping invalid start byte b'E'
13:05:14.918 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc7'

Some local buttons for module 5 :

TRIGERRING ON THEN OFF LOCAL BUTTON 6, MODULE 5 (ADDRESS 4.5)
13:12:24.929 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:25.153 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x1d'
13:12:29.240 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:29.474 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x1d'

TRIGERRING ON THEN OFF LOCAL BUTTON 7, MODULE 5 (ADDRESS 4.6)
13:12:33.332 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:33.332 WARNING (MainThread) [biomatx] dropping invalid start byte b'.'
13:12:33.546 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:33.546 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x0e'
13:12:37.344 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:37.344 WARNING (MainThread) [biomatx] dropping invalid start byte b'.'
13:12:37.559 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:37.560 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x0e'

TRIGERRING ON THEN OFF LOCAL BUTTON 8, MODULE 5 (ADDRESS 4.7)
13:12:41.108 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:41.312 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x1c'
13:12:44.762 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:44.917 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x1c'

TRIGERRING ON THEN OFF LOCAL BUTTON 9, MODULE 5 (ADDRESS 4.8)
13:12:48.426 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:48.426 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xcb'
13:12:48.631 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:48.631 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc3'
13:12:52.210 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:52.210 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xcb'
13:12:52.454 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:52.454 WARNING (MainThread) [biomatx] dropping invalid start byte b'\xc3'

TRIGERRING ON THEN OFF LOCAL BUTTON 10, MODULE 5 (ADDRESS 4.9)
13:12:56.072 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:12:56.247 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x1b'
13:13:00.205 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x15'
13:13:00.400 WARNING (MainThread) [biomatx] dropping invalid start byte b'\x1b'

I can’t help noticing that :

• Several actions seem to produce the same results in the log (I swear that in real life, different light channels turn on and off…).
• Some actions on module 5 produce shorter results (only 2 lines of log per action instead of 4).

EDIT : Removed DATE from logs so as to make the whole thing easier to read (no horizontal scrolling required)

[canatella (Damien Merenne)]

About the baudrate, when using a serial to tcp converter, the baud rate and all the serial parameters in the integration python codes are ignored. The adapter takes care all by itself of the serial parameters. The one in the integration are when using a serial port directly connected to the home assistant device, like a serial to usb adapter.

I’m sure the speed is ok for my installation. I got it by trial and errors, but if you’re receiving the invalid bytes stuff, it probably means its correct.

As for the logs, indeed, really strange that some addresses trigger the same bytes. The problem might be that some bytes are accepted and so all of them are not logged and the logs might be missing some?

The best way to know this would be to connect to the serial-tcp adapter directly. Are you on a Linux box ? If so, running nc 192.168.34.244 4196 | hd and press the buttons should display the unprocessed bytes directly from the adapter as an hexadecimal dump (you might need to install netcat).

[JeromeB]

Here’s the hex dump from several operations, run from macOS 11.7.10 on some x64 CPU (I did not have a Linx box at hand)…

Local button (on a module) vs. remote push button (wired through dedicated input) :

• Trigerring ON then OFF push button on dedicated input 8, module 1 (address 0.7)
• Trigerring ON then OFF local button 8, module 1 (address 0.7)

$ nc 192.168.34.244 4196 | hexdump -x
0000000    fe45    fc45    fe45    fc45    fe45    fc45    fe45    fc45

→ Triggering using a local button or a dedicated input seems to result in the same message on the bus.
→ Address 0.7 seems to send message fe45 fc45

Module 1 :
Trigerring ON then OFF each local button (from 1 to 10) on module 1 (so addresses 0.0 to 0.9, twice each) gives the following output :

$ nc 192.168.34.244 4196 | hexdump -x
0000000    fec5    fcc5    fec5    fcc5    fe45    fc45    fe45    fc45
*
0000020    9fc5    8fc5    9fc5    8fc5    9f45    8f45    9f45    8f45
0000030    fec5    fcc5    fec5    fcc5    fe45    fc45    fe45    fc45
0000040    cfc5    c7c5    cfc5    c7c5    cf45    c745    cf45    c745

The * on second line means it’s the same as the first line, so I double checked the results running sequences in different orders… Line 4 is also the same… So, as you can see :

• Address 0.0, 0.2 and 0.6 all give fec5 fcc5
• Address 0.1, 0.3 and 0.7 all give fe45 fc45

Complete table :

Module	Button	Address	Hex dump
1	1	0,0	fec5 fcc5
1	2	0,1	fe45 fc45
1	3	0,2	fec5 fcc5
1	4	0,3	fe45 fc45
1	5	0,4	9fc5 8fc5
1	6	0,5	9f45 8f45
1	7	0,6	fec5 fcc5
1	8	0,7	fe45 fc45
1	9	0,8	cfc5 c7c5
1	10	0,9	cf45 c745

→ I can’t understand what is going on with the module 1 address scheme !

• All the module settings have been checked, nothing special to see here.
• Module has been factory reset anyway and set back to its address, same results.
• Module addresses have been swapped, “new” module 1 behaves the same way (so it’s the address scheme, not some issue with a specific physical module)

→ I can’t help thinking we are missing something on the serial bus side. Bitrate, parity/error correction, data bits, etc… Can you maybe check the settings on your own IP/RS485 bridge ? Also, can we think of anything else on that side, like some format/code conversion, etc ?

Modules 2, 3, 4 and 5 :
I was able to identify the following buttons :

Module	Button	Address	Hex dump
2	1	1,0	e757 e357
2	2	1,1	7757 3757
2	3	1,2	3b57 1b57
2	4	1,3	7657 3657
2	5	1,4	9d57 8d57
2	6	1,5	7557 3557
2	7	1,6	3a57 1a57
2	8	1,7	7457 3457
2	9	1,8	ce57 c657
2	10	1,9	7357 3357
3	1	2,0	f32b f12b
3	2	2,1	6f2b 2f2b
3	3	2,2	372b 172b
3	4	2,3	6e2b 2e2b
3	5	2,4	9b2b 8b2b
3	6	2,5	6d2b 2d2b
3	7	2,6	362b 162b
3	8	2,7	6c2b 2c2b
3	9	2,8	cd2b c52b
3	10	2,9	6b2b 2b2b
4	1	3,0	e656 e256
4	2	3,1	6756 2756
4	3	3,2	3356 1356
4	4	3,3	6656 2656
4	5	3,4	9956 8956
4	6	3,5	6556 2556
4	7	3,6	3256 1256
4	8	3,7	6456 2456
4	9	3,8	cc56 c456
4	10	3,9	6356 2356
5	1	4,0	f915 f815
5	2	4,1	5f15 1f15
5	3	4,2	2f15 0f15
5	4	4,3	5e15 1e15
5	5	4,4	9715 8715
5	6	4,5	5d15 1d15
5	7	4,6	2e15 0e15
5	8	4,7	5c15 1c15
5	9	4,8	cb15 c315
5	10	4,9	5b15 1b15

→ There seems to be no redundancy whatsoever for these modules.

[canatella (Damien Merenne)]

Are you sure about the module addresses ? Here are the actual bits that are sent:

1.0 e757 e357 1110011101010111 1110001101010111
1.1 7757 3757 0111011101010111 0011011101010111
1.2 3b57 1b57 0011101101010111 0001101101010111
1.3 7657 3657 0111011001010111 0011011001010111
1.4 9d57 8d57 1001110101010111 1000110101010111
1.5 7557 3557 0111010101010111 0011010101010111
1.6 3a57 1a57 0011101001010111 0001101001010111
1.7 7457 3457 0111010001010111 0011010001010111
1.8 ce57 c657 1100111001010111 1100011001010111
1.9 7357 3357 0111001101010111 0011001101010111
2.0 f32b f12b 1111001100101011 1111000100101011
2.1 6f2b 2f2b 0110111100101011 0010111100101011
2.2 372b 172b 0011011100101011 0001011100101011
2.3 6e2b 2e2b 0110111000101011 0010111000101011
2.4 9b2b 8b2b 1001101100101011 1000101100101011
2.5 6d2b 2d2b 0110110100101011 0010110100101011
2.6 362b 162b 0011011000101011 0001011000101011
2.7 6c2b 2c2b 0110110000101011 0010110000101011
2.8 cd2b c52b 1100110100101011 1100010100101011
2.9 6b2b 2b2b 0110101100101011 0010101100101011
3.0 e656 e256 1110011001010110 1110001001010110
3.1 6756 2756 0110011101010110 0010011101010110
3.2 3356 1356 0011001101010110 0001001101010110
3.3 6656 2656 0110011001010110 0010011001010110
3.4 9956 8956 1001100101010110 1000100101010110
3.5 6556 2556 0110010101010110 0010010101010110
3.6 3256 1256 0011001001010110 0001001001010110
3.7 6456 2456 0110010001010110 0010010001010110
3.8 cc56 c456 1100110001010110 1100010001010110
3.9 6356 2356 0110001101010110 0010001101010110
4.0 f915 f815 1111100100010101 1111100000010101
4.1 5f15 1f15 0101111100010101 0001111100010101
4.2 2f15 0f15 0010111100010101 0000111100010101
4.3 5e15 1e15 0101111000010101 0001111000010101
4.4 9715 8715 1001011100010101 1000011100010101
4.5 5d15 1d15 0101110100010101 0001110100010101
4.6 2e15 0e15 0010111000010101 0000111000010101
4.7 5c15 1c15 0101110000010101 0001110000010101
4.8 cb15 c315 1100101100010101 1100001100010101
4.9 5b15 1b15 0101101100010101 0001101100010101

For the module address, you would expect to see ten 01 (1) then ten 10 (2) then ten 11 (3) and ten 100. The 9th column (bit[9]) seem to be the lowest significant bit, it alternates between 1 and 0 when the module address increases. Then bit[8] is clearly not a candidate for the 2 significant bit. It should be ten 0 then ten 1 then ten 1 then ten 0 again (01, 10, 11, 100). If the bits are encoded in reverse order, bit[10] could be it but it doesn’t match for module 3, which would be address 5 instead. If module 3 is in fact module 5, then bit[9…11] would be the address of the module…

For the switch address, I would expect to see a column of alternating 1 0 1 0 with the switch address increasing … but there are none…

Mystery deepens… Maybe try to reconfigure each module’s address. And are all relays configured in “telerupteur” mode ?

[JeromeB]

Hello again,

About the biomatX setup :

• I’m pretty sure about the addresses but checked them for the billionth time anyway !
• All relays are set to “telerupteur” mode, except two of them that control dimmers, so we can leave that aside (I think they won’t work with the integration but that’s a small side issue at this point).

I have tried reversing the polarity once again, which I did initially two or three weeks ago. I remember the integration didn’t start at all back then, connecting to the RS485 bridge gave error messages, so I figured it did put itself in some form of safety mode when reversing polarity. But the error must have been caused by something else, as it now works and is giving much more consistent results. Have a look :

MODULE 1 (ADDRESS 0)
0,0 0050 8050
0,1 0150 8150
0,2 0250 8250
0,3 0350 8350
0,4 0450 8450
0,5 0550 8550
0,6 0650 8650
0,7 0750 8750
0,8 0850 8850
0,9 0950 8950
MODULE 2 (ADDRESS 1)
1,0 1051 9051
1,1 1151 9151
1,2 1251 9251
1,3 1351 9351
1,4 1451 9451
1,5 1551 9551
1,6 1651 9651
1,7 1751 9751
1,8 1851 9851
1,9 1951 9951
MODULE 3 (ADDRESS 2)
2,0 2052 a052
2,1 2152 a152
2,2 2252 a252
2,3 2352 a352
2,4 2452 a452
2,5 2552 a552
2,6 2652 a652
2,7 2752 a752
2,8 2852 a852
2,9 2952 a952
MODULE 4 (ADDRESS 3)
3,0 3053 b053
3,1 3153 b153
3,2 3253 b253
3,3 3353 b353
3,4 3453 b453
3,5 3553 b553
3,6 3653 b653
3,7 3753 b753
3,8 3853 b853
3,9 3953 b953
MODULE 5 (ADDRESS 4)
4,0 4054 c054
4,1 4154 c154
4,2 4254 c254
4,3 4354 c354
4,4 4454 c454
4,5 4554 c554
4,6 4654 c654
4,7 4754 c754
4,8 4854 c854
4,9 4954 c954

Sure enough, the integration now seems to be working ! I still have to properly configure my reset scenario on all 5 modules, and see how things behave in the upcoming hours and days. I’ll report here any glitches I meet.

In the meanwhile, in order to redeem myself for overlooking the polarity issue (which I really thought had been taken care of), I’ll make sure to write and publish a detailed guide with all the info I’ve gathered, maybe you can review it later… Who knows, a third user might show up some day !

Many thanks !

[canatella (Damien Merenne)]

Nice, glad to hear it finally worked

I didn’t thought the polarity would influence the decoding. I thought it used the potential difference between the two lines to decode bits, but it seems the A line is the reference one, and the B one is the inverse line. Good to know…

Also I think you don’t need to setup a reset on all modules. On my installation, with the modules interconnected, it’s one scenario on one module triggering the reset on all 3 modules. The manual says on page 17:

Un Bp de commande de scénario peut commander des relais de différents modules BioMatX II pour autant que ceux-ci soient connectés par le “réseau intermodule” (RJ 45)

So you just go into scenario config mode on one module, then select all the relay on all modules, then disable them, then save and you should be good.

I’ll update the readme with your doc, thanks!

[JeromeB]

Hello again Damien,

About the all_off scenario

I initially read that line in the user guide the same way you are.

But when you go about configuring your scenario, only the relays in the module you are working from can be added. I just tested this again. I had to setup the behavior of the 10 relays on each of the 5 modules individually, of course with the same scenario number on each module.

Unless you can double check and confirm another behavior, I will make sure to mention this in the guide I’m drafting.

My two cents :

If you think about the way the system works, it makes sense. Basically a scenario is just tied to a button address on a non-existing module with address 7, and you are just telling each module how to behave with regard to their own relays when they receive this address on the bus.

HA integration aside, a scenario could therefore be triggered either by a switch on the Anabus set to the proper address (on “virtual” module with address 7), or by some other device broadcasting the same signal (the MEWS Lt module or, in our case, an ETH/RS485 bridge).

But as the user guide states that you can also use an 8th module if you do not use any scenarios, I’m pretty sure that in a setup without the Anabus (using push buttons on dedicated inputs) you could still configure scenarios and trigger them by using the dedicated digital inputs on a module with address 7 where all the relays remain unused.

Binary_sensor entities behavior

How are these supposed to work, both in terms of behavior and from a technical perspective ?

They do not seem to show correct status with regard to the related light entity, when my understanding is that they should be giving the same instant information (relay is on or off) as well as an history of the entity status. There seems to be some sort of delay between an actual change of light entity status and the subsequent binary_sensor entity status change.

Example 1 : this light is currently on (and has been for 10-15 minutes) but the status is not updated. Although it was on for a brief period during the afternoon and that seems to have been recorded (although I could not tell if the information is accurate, I’ll have to experiment a bit more for that).

Example 2 : this light is currently on as well, but the status is not updated. Furthermore, it HAS been on earlier this afternoon, for several minutes and possibly more but the entity history always has an OFF event immediately after the ON event. This seems to be the most frequent behavior even for devices that occasionally show more plausible status history.

Multiple activities on the bus

While gathering the messages this morning using netcat, after having properly connected the wires, I noticed that the messages seem to get mixed together if several users happen to be hitting switches simultaneously in different parts of the house (with a 42 relays setup spanning 3 floors and a family of 7, this is bound to happen). I did not spend much time on this and it will be tricky to reproduce, but it looked like some of the info got lost.

Any experience with this or thoughts on the matter ?

Color modes

There’s a warning message in the logs each time the integration is started. My understanding is that light entities will have do declare their supported color modes to HA in the future, or the integration will stop working with future releases. Do we have to worry about this ?

Log details (WARNING)
Logger: homeassistant.components.light
Source: components/light/__init__.py:1272
integration: Light ([documentation](https://www.home-assistant.io/integrations/light), [issues](https://github.com/home-assistant/core/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+light%22))
First occurred: 8:21:08 AM (200 occurrences)
Last logged: 8:52:08 AM

None (<class 'custom_components.biomatx.light.BiomatxLight'>) does not set supported color modes, this will stop working in Home Assistant Core 2025.3, please report it to the author of the 'biomatx' custom integration

[canatella (Damien Merenne)]

Indeed, it makes sense that the same scenario address is mapped on each module. I probably did that but don’t remember about it.

The binary sensors are mapped to the switches. They are on when the corresponding button is pressed, and off when the button is released.

The relays are the light entities.Their status is based on what the integration thinks their status is as I haven’t found a way to ask the modules their current states (and that’s the reason for the all off scenario, to reset the state on hass starting up).

About multiple users pressing the switches at the same time: with the anabus, the problem is worse as it’s not even registering the press, or it’s lighting up an unrelated light. What is received on the serial bus is what was generated by the modules, we don’t control that. On the integration side, we could try to add some state so that when we could receive the start byte multiple time and expect the corresponding number of second bytes with the switch address. But this might get tricky, and if it’s hard to reproduce it will be hard to get that right too. But if you find a way to easily reproduce it, or if you can see that it’s just always first byte for switch X then first byte for switch Y then second byte for switch X and second byte for Y, without the actual byte content being mixed, then it might be worth a shot.
Thinking about it, I could also simple ignore the start bytes… not sure if there are any other kind of packet sent on that bus, I’ve never seen any.

About the error message, I’ll update the integration to fix it.

UPDATE: I pushed the fix for the warning.

[JeromeB]

Hello,

Thanks for the details.

I take it the binary sensor should not remain ON using push buttons and télérupteur mode. Only if the user keeps the button pressed should it stick to ON, or in case of missing/improper bus signal.

Light entities are understood. I figured that was the purpose of the all_off scenario. Do you experience loss of sync in normal use ? I was thinking about restarting the integration on a regular basis to avoid lingering loss of sync, but haven’t experienced any.

Except with the one relay set in contacteur mode to drive a dimmer :

• It works fine detecting on/off status with one press ;
• I haven’t really tested maintaining the button to slowly change the dimmer intensity but that should be considered as one button push. If the user turns the light on with one quick push and then maintains the button through a second push to change intensity, the integration will consider the relay is now off when the light is actually still on.
• Likewise, doubleclicking the button to set the dimmer to max is interpreted as two pushes, so if you’re starting from an off status, the light is now on but the integration considers it off again. If you’re starting from an on status, the light is set to max and the integration considers it on after having been briefly turned off.
  → Not much can be done unless the integration is updated to ask the user to specify such setups on installation, and accordingly process the signals form the bus. That’s some work for a feature that I don’t really need, and so far I’m the only known user, so don’t consider this a request !

Finally, how do I update the integration ? Just download the files again and overwrite them in my existing folder ?

Extra question : how would a user proceed with adding an extra module (hey, they’re still being sold, I did consider using them for my extension to the 3rd floor) ? Where would one manually edit settings so as to avoid importing the integration again (and having all their existing entities considered as new, with all the consequences on existing rules) ?

[canatella (Damien Merenne)]

The binary sensors are really modelling the physical button, so if the button is pressed, it should be on, if the switch is released it should be off. It’s working fine here, it’s basically turning on when receiving the 2 bytes for a button press, and turning off when receiving the released bytes. Isn’t this the behaviour for you ? I’m using this to bind unrelated command to switches here, like commanding a zigbee smart plug instead of a biomatx relay. Nice thing is that you can implement double click or stuff like that.

It rarely goes out of sync nowadays. It calls it at start up but there’s also a service for calling it named biomatx reset. When resetting, it actually calls the all off scenario and then turn on the light that were on before, so you just notice the light flickering. I have an automation to turn on the lights at night, and just before doing that it calls the biomatx reset service so it’s not noticeable because most lights are off at that moment.

I had a dimmer once, but I never bothered with the integration for it. It’s complicated both to interpret. You kept the button pressed for 2 second, what does it mean ? light went up by 20% or down by 20%? And same for using it, how long should it simulate a button press to bring lightness up by 50% ? Where I need dimming, I put zigbee bulbs and I use scenes so I never modify the brightness manually.

There’s another person with a biomatx that actual as the mews module who contacted me few weeks ago, he wanted to look at how it was controlling the modules. Maybe there’s some specific message types to get the modules to manage a dimmer, but I’m really not sure about that.

To update, just overwrite the file and restart hass.

To add a module, I think one would need to implement the configuration dialog which I never did, as I never changed that but I can have a look at it. Enersol are the ones who are managing this product now. I already asked them for the protocol, but I never got anywhere with it. If you buy a new module from them, it would be nice if you could get the specification for it at the same time.

All in all, it’s not the fanciest system, but it’s simple, works well and with home assistant you get the bell and whistles of a more expensive system so I’d buy a new module too if I ever needed more relays.

[canatella (Damien Merenne)]

I pushed an update implementing the reconfigure flow, you might want to try and see if it works (integrations → biomatx → three dots → reconfigure) before you start with automations and stuff.

[JeromeB]

Quick update :

• Binary sensors behave as you described.
• Funny coincidence, I got an out of sync event this morning, triggered by an other family member in the kitchen using in-wall buttons. I looked at the binary sensor history. The button was activated twice in a row, very quickly. I guess so quickly that the HA integration recorded it while the BiomatX module itself dropped it.
• Will be doing something similar, a daily or bi-daily reset. Haven’t had time to play with it yet.
• Forget about dimmers.
• Sure enough, analyzing the MEWS messages might teach us new things. I like to think most of the software runs locally and results in simple messages similar to the ones your integration generates. If it needs to configure modules, I suppose we’ll see it send messages using buttons 11 and 12 (addresses 10 and 11) in conjunction with other buttons to send basic settings to the modules.
• Updates integration installed.
• Haven’t checked for the color warning in the logs, I suppose it is gone.
• Had a look at the “reconfigure” feature, the pop up dialog appears, I didn’t actually use it as my setup is fine now. Welcome addition, however.
• I agree with your conclusions about the system. However, for my extension, as it’s a distinct electrical panel and as I had to take a decision before being sure your integration even existed at all, I went another way and ordered GCE Electronics set of modules (IPX 800 v5 and an extra 8-relays module). This gives more flexibility and will integrate with HA anyway. IU don’t think I’ll be using a lot of the IPX 800 features, most automatisms will live in HA so as to keep things in one central place.