Forum

Browse topics, discover Works With Legrand community!

Confusions: Home + Control / Security App / Devices

<p>Dear All,</p><p>I’m totally confused.</p><p>I own Legrand 752196 Valena Life with Netatmo Gateway with some shutters and switched, where i use the Home+Control App.Then I have the Dorr Entry System Classe 300EOS, where I use the Security App. Both devices are conneted with the same Netatmo account. I need to give them individual home names and can’t set them to the same name or rearrange them in the same home group. Why is it not possible to set them in the same home group?</p><p>In the Home+Control App, I can switch in between both homes. Both are showing the same devices in the dashboard, but ion the settings, in one a can set properties for teh devices like shutters, the other home for set up the door entry system.</p><p>Same for the website (https://home.netatmo.com/control/dashboard), where i just see the energy dashboard, not the devices, but in both homes there is nothing shown under security?I’m totally lost. Is the door entry system a security device or not…? why is it not visible?</p><p>The background is that i recently have troubles with the Netatmo Home assistant intregration, which won’t work anymore. I see troubles from a lot of people, who added the Classe 300EOS top the same account as other devices. Something with the rooms causes troubles.”File “/usr/local/lib/python3.13/site-packages/pyatmo/home.py”, line 184, in update self.rooms[room[“id”]].update(room)”</p></p>

Hello Manuel,

The Classe 300EOS with Netatmo is a BUS SCS device. The 752196 Gateway and devices linked are communicating via ZigBee. And they are indeed in separate apps Netatmo’s native apps. I think that why we force to have the C300EOS in a separate Home

Concerning the webapp (https://home.netatmo.com/), the C300EOS is simply not integrated to it. As far as I know it’s not planned to do it

This being said, it does not impact or have something to deal with the ability to access the device via 3rd party API calls. Do you have a link to conversations talking about this with Home Assistant ?

Have a good day,

Leslie – Community Manager

<p>Understood that there are different systems and different apps, even it’s strange that the Classe 300EOS is not well implemented. To be honest, I haven’t really understood “Evolution of Smart”. The idea is good, but the implementation is somehow 5-10 years behind. Answering the phone takes so long that the visitor has already left, the door station has a serious vulnerability, and basic features and settings are missing. But that’s a different issue.</p><p> </p><p>Some topics regarding the faulty integration with Home Assistant once the Classe 300EOS is added to the account:</p><p> </p><p>https://community.home-assistant.io/t/problem-with-netatmo-bticino-integration-error-setting-up-entry-home-assistant-cloud-for-netatmo/514764</p><p> </p><p>https://github.com/jabesq-org/pyatmo/issues/534</p><p> </p><p>https://github.com/home-assistant/core/issues/85594</p><p>On Github there are some more bugs in respect to classe 300 EOS, which causes troubles in the official netatmo integration</p><p> </p><p> </p>

Hi Manuel,

I just discussed with an other user having a similar issue. It seems like HA doesn’t correctly manage the case where a C300EOS is present with other Legrand/Bticino/Netatmo devices in a same end-user account

On API side (our side), I don’t see any reason for this strange behavior. The JSON structure of responses is not different from the ones of other devices (presence of home/device_id, ability to perform calls to the same /homestatus and /homesdata endpoints, …)

Here is a complete feedback the user sent me. In his conclusion, the C300EOs was only recognised by HA when using it via a different Netatmo end-user account. On my side I don’t see a relevant reason for this :

 

API behavior observed

From Home Assistant (via pyatmo), I observed the following:

  • When controlling NATherm1 + Valves, Home Assistant calls:

    • /api/setstate

    • This results in 406 - Not Acceptable - Nothing to update (7)

  • As you correctly pointed out, NATherm1 should use /setroomthermpoint, not /setstate.

  • When a Smarther2 (BNS) is present, /setstate is valid and works as expected.

This suggests that Home Assistant / pyatmo may not correctly switch endpoints when multiple heating systems coexist in the same Home.


Polling issue details

A second, very relevant issue I encountered concerns polling:

  • After revoking third-party authorizations, polling stopped completely:

    • Entities remained frozen at the last known state.

    • This affected weather station data as well.

  • The same polling issue occurred even with a brand-new Netatmo account, immediately after first authorization.

  • Polling only restarted correctly after:

    • Fully removing the Netatmo integration from HA

    • Re-adding it once EOS300 was no longer present in the account

This suggests that:

  • Device classification during /homesdata or initial subscription may be impacted by the presence of EOS300.

  • Backend state or cached device topology may influence polling initialization.


Final working configuration

The configuration that finally works reliably is the following:

  • New Netatmo account created from scratch.

  • 3 Homes recreated manually.

  • Each heating system placed in a dedicated Home:

    • NATherm1 + Valves in their own Home

    • Smarther2 (8002X) in a separate Home

  • EOS300 kept completely outside this account

With this setup:

  • /setroomthermpoint calls work correctly.

  • No more 406 errors.

  • Polling works consistently.

  • Home Assistant correctly detects all devices.


Main conclusion

Based on all tests, I strongly believe the primary source of instability was the association of EOS300 in the same Netatmo account used for heating devices.

Once EOS300 was removed:

  • API behavior normalized

  • Polling stabilized

  • Device discovery became consistent

Have a good day,

Leslie – Community Manager

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.