This is the difference
I tried to call service myhome.send_message, and read data from bus with node-red, the answer is correct, but the data show is not correct.
I get from gateway 20.3 but in frontend there is 20.6
Yes, I’ll try to give you all the help I can !
Thank you very much appreciated, surely you will be able to explain better than me :0)
This is the difference
This is interesting, knowing the status of the valve whether it is on or off! In addition to the set point and local offset.
I get from gateway 20.3 but in frontend there is 20.6
Yes, this often happens to me too, it seems, as written in the readme…
It is possible that upon first install (and updates), the OWNd listener process crashes and you do not get any status feedback on your devices. If such is the case, a restart of Home Assistant should solve the issue.
…that listening to the bus crashes, but it also happens to me for no apparent reason.
Activating debugging,
#configuration.yaml
logger:
default: warn
logs:
custom_components.myhome: debug
I see all the correct data! it is as if in the frontend it does not take the data.
Example log
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *#4*4*0*0179##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *4*1*1##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *#4*1*12*0185*3##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *#4*3*0*0184##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *#4*3*14*0185*3##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *#4*4*0*0179##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *#4*2*13*00##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *4*311*#2##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *4*110*#2##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *4*1*4##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *#4*3*13*00##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *4*311*#3##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *4*110*#3##
2020-12-11 21:30:14 DEBUG (MainThread) [custom_components.myhome] Received: *#4*4*14*0185*3##
2020-12-11 21:30:15 DEBUG (MainThread) [custom_components.myhome] Received: *#4*4*13*00##
2020-12-11 21:30:15 DEBUG (MainThread) [custom_components.myhome] Received: *4*311*#4##
2020-12-11 21:30:15 DEBUG (MainThread) [custom_components.myhome] Received: *4*110*#4##
2020-12-11 21:30:17 DEBUG (MainThread) [custom_components.myhome] Received: *#4*1#1*20*0##
2020-12-11 21:30:18 DEBUG (MainThread) [custom_components.myhome] Received: *#4*3#1*20*1##
2020-12-11 21:30:19 DEBUG (MainThread) [custom_components.myhome] Received: *#4*4#1*20*1##
2020-12-11 21:30:20 DEBUG (MainThread) [custom_components.myhome] Received: *#4*2#1*20*0##
we wait for Julien what he tells us :0)
Hi guys,
My main goal was to use the facilities provided by Home Assistant and try not to add custom patched up parts together.
So right now, I continuously listen on the event bus for data coming in, the messages are turned into python “objects” by the library and passed along to the integration to update status of various entities.
I worked around the limitations of the Home Assistant climate entity as best I could, so I update the valve status as documented.
If the valve is on or off I update the HVAC_Action, now I don’t know if this does anything in the frontend. 
The local offset is integrated as well. If I take a zone for example, let’s say zone 1:
If you have the temperature set to 20°, the frontend will show 20°.
Now if you dial the local offset to +3°, the frontend will show 23°.
Now if you set the frontend temperature back to 20°, it will set the temperature to 17°, so with the local offset it will show 20°.
Now if you dial the local offset back to 0°, it will show 17° in the frontend.
I’m not sure I explain this correctly…
Then for the 0.3° difference you have… I’m really not sure what’s happening!
Having a few logs would likely help 
Hi all,
I did some testing and it seems as if the variations along the event bus were not read.
If you restart the system all the data is correct, but then it won’t update anymore. Activating the logs, I see all the commands and responses of the command bus, but nothing of the event bus is seen, is that correct?
I confirm that on restart the system recognizes the offset on the set temperature. But as mentioned later there is no longer any update.
I also see the problem on the lights, after a while the switch on command works the light turns on, but the status in HA does not change.
The light can no longer be turned off by HA, because having not updated the status it is turned off. If I turn it off from the switch on the wall and try to turn it back on from HA the command works again but the status does not update
I think the problem is reading the event bus or updating the HA due to changes in the event bus
Does this happen every single time?
Do you have logs of what happens when the event listener crashes?
I am installing a second home assistant on a second raspberry, because I see that having node red - mqtt and myhome active at the same time querying the same gateway creates problems.
So I create a forklift to do the tests with your integration so that I can do all the tests.
Yes, what you say is all right!
Ok, I made the video clearer and sent it to you in pvm, along with the log file.
From there you can see how your component works perfectly!
All settings are taken correctly, but what’s wrong is the lovelace part, so in the frontend.
I hope the video is clearer than words … and that it can help. 
Thanks for your time and interest. 
edit
I almost forgot … and thanks for adding the slave probe sensor 
I’ve the same issue. When you restart HA , it won’t update anymore. I found how to restart it. Just go to the integrations, choose MYHOME, click on the three dots at the bottom right and click “reload”. The integration restart and all is updated.
1 Like
Unfortunately I had already tried, but in my case it doesn’t work. 
I just have errors similar to this for all components
2020-12-13 12:24:22 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry MH201 Gateway for light
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 236, in async_setup
result = await component.async_setup_entry(hass, self) # type: ignore
File "/usr/src/homeassistant/homeassistant/components/light/__init__.py", line 265, in async_setup_entry
return await hass.data[DOMAIN].async_setup_entry(entry)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 155, in async_setup_entry
raise ValueError("Config entry has already been setup!")
ValueError: Config entry has already been setup!
Maybe it is due to the non-gateway device? (MH201) I do not know…
Maybe, could it be that I have the recorder in memory? Now I have put the default database back on file.
And let’s see what happens.
edit
Nothing, just by sending the status request frames of the type message: "*#1*0##", everything works again.
EDIT2 Yes, it works go here
Unfortunately it is exactly the same problem that I also had when I tried to develop the integration, the command bus works but the updating of the status of the lights does not work.
I only installed myhome on a new raspberry and it works the same as I saw yesterday.
As soon as it is started, the component works perfectly, but after a while it stops receiving updates from the event bus.
So a light that is off can be turned on from HA, but then by not updating the status in HA ,it is turned off in HA even if it is on and therefore it is impossible to turn it off.
If you turn it off from the wall switch then the status that does not update returns to be correct however and you can then turn it back on.
The same happens if one turns on the light from the wall switch, the status does not update and therefore it is impossible to turn it off from HA.
This is good or bad the same problem I had, the library that read the two buses, even in my case it worked fine, but then the problem was interfacing with HA.
That’s why I switched to node-red and MQTT.
If I’m not mistaken, Sdomotica works because it also passes through MQTT to interface.
Maybe you could keep the OWNl but instead of sending data from a custom component, switch to MQTT and leave interface management to this component.
It was something I wanted to try, but then found that with node-red the creation of the interface between OpenWebNet and MQTT was easily achievable, I opted for this choice.
The system works well, only sometimes it requires the restore of flows in node-red but then everything comes back perfect for weeks.
I send another image that maybe can help.
As you can see in the image up to 18:45 the system works perfectly, when a command is sent, opens the command session, sends the message, closes the session and receives the event bus status, by updating the interface.
At 18:45 it also receives the heating data (not configured for now).
I wait two minutes, and send a new command to turn off a light.
The command session is opened, the command is sent, the session is closed, but no more messages arrive from the event bus.
From here on the system crashes, and you have to restart HA.
The reason I developed this integration and library is specifically to NOT use MQTT
I don’t feel there would be a benefit to add another abstraction layer in the mix.
The problem you are facing is really really strange, and of all the people testing this so far, you are only the second person to report it.
Can I ask what type of gateway you have? Is it running the latest firmware?
Many people will encounter at one time or another a crash of the event listener that I can’t explain, but it’s rare and is usually solved by a single restart of Home Assistant.
For me the integration is largely stable enough that I update Home-Assistant to a new version before needing to restart it because of a crash.
As I said, there’s only been two reports of this being systematic after 2 or 3 minutes…
strange. no, I don’t have this type of problem, the bus update works and the energy consumption continues to send every change of state. The reading request is made only once every two hours, as suggested in Julien’s readme. However, I found my problem, that is, I have an actuator that is not seen with the general status request … it is a 3475, I have to check if it is configured manually and how. It was this actuator that was NOT updated ONLY with general status requests, in fact, if I turn it off or on, it updates regularly. For the rest of the lights and switches and sensors everything is fine and I’m using an MH201.
3475
I have a HL4684 it is a touch screen with latest firmware
I have an idea ! I remember the in my integration, I did not close the command session to each command, as you do, but I left it open. But to keep it on I had to add a watchdog, a command every 1:30 min on the command bus ( I send a command not recognized so that the bus answered with a NACK) Maybe the problem is this, my touch screen is not an ufficial gateway and maybe it requires this continuous awakening in order to also keep the event bus active
Do you think it s possible to add something similar to your library ?
Unfortunately, this would be a massive change!
I played around with this idea on my previous system (I used to have Jeedom, and I heavily updated the MyHome plugin to add many new features), but I found that on my system (an F454 with firmware 2.0), I could not keep a command session alive like this.
Even with keepalive messages, it kept closing after about 90 seconds.
So this workaround that is apparently necessary for your gateway might not even be possible for other systems.
Unfortunately, this is a part of the MyHome ecosystem that is really poorly documented by Legrand/BTiicino…
Those simple TCP session count and timeout limits are available nowhere and can only be guessed on a case by case basis.
Hi Julien, good news !
I managed to solve the watchdog problem.
I created a fake light with a non-existent address and then I added an automation that turns on that light every minute.
Obviously nothing happens either in HA or on the system, but this causes the event bus to respond with a NACK and this keeps the connection alive.
Now not only the lights work, but also the temperature values indicated by the thermostats and the set temperature.
All that remains is the local offset and status of the valves or rather the actuators.
For the offset problem.
The data is not updated.
However, when the set temperature is updated then it takes into account the offset.
From the listing of the program I see that you have two values
message.local_set_temperature
that becomes
_local_target_temperature
and
message.set_temperature
which adding the offset always becomes
_local_target_temperature
When the set temperature changes
message.local_set_temperature
is sent already corrected with the possible offset and everything works, but if the offset is changed for some reason the calculation
_local_target_temperature = self._target_temperature + self._local_offset
does not happen.
However, I don’t know if this happens at the OWNl level or in the custom component. It would take some additional logs to figure it out.
The HA log show that the data from event bus arrive
Cool, I’m glad that you found something that allows the connection to keep going
For the offset, I fixed a bug about that yesterday with @caiosweet’s help.
It was indeed a problem with the _local_target_temperature never being actively calculated because I expected the bus to always send the dimension 12 when the local offset is changed, but it happens rarely in reality.
Are you running the latest version of the code from the master branch?
I also fixed (or I think I fixed…) a bug relating to the valve and actuator status tonight, but it’s not been tested yet.
Once these issues are fixed (and confirmed fixed) I’ll package it into a new release version.