Comparison to existing 2N integration

[moritzj29]

Hi @genka13 I just stumbled upon your new 2N integration while checking the brands repository for a 2N logo. Since your component appears to be quite new / still actively developed, could you loose some words on what is different to the existing implementations of the 2N API? (e.g. https://github.com/SVD-NL/helios2n-hass)
I have been using that one for a while but it appears to be no longer actively maintained.
Thanks!

PS: at least having the logo in place is a nice plus ;)

[genka13]

Hi @moritzj29, thanks for reaching out and for noticing the logo 😄

A similar question was already raised over at py2n-intercom#1, so I'll summarize the key points here as well.

I haven't done a formal comparison with the existing implementations. The main reason for starting a new integration was to have full control over the development and testing cycle while the architecture is still being defined. The 2N API communication itself is relatively straightforward, so building a dedicated library made it easier to iterate quickly.

I'm currently validating the component with several newer devices:

• 2N IP Style
• 2N IP Verso 2
• 2N IP One

Beyond that, I'm also preparing support for My2N and 2N Access Commander. I have 2N Fortis products set up for testing as well, but since their communication runs via the Access Commander, I need to get a full overview of the possibilities first.

Once the architecture is more stable and the scope is clear, I'm open to collaboration or consolidation with existing efforts.

[moritzj29]

Thanks for the write-up! Sounds interesting, I will definitively watch the development of the library. I think it is very nice to have more people actively working on open-source code for the 2N platform. I think @cbergmann is also quite active currently implementing fixes and extensions over at py2n and helios2n-hass. Unfortunately, especially on the custom component side of things most of the libraries look quite stale with PRs being not merged for quite some time (original SVD-NL repo at least).

I have been looking into this in the last days because I'm also working on the integration of my 2N system: https://github.com/moritzj29/relay_emulator_2n I needed a secure way to signal door open or doorbell signals to my home assistant instance and was not satisfied with using the HTTP API (polling) or unprotected Home Assistant webhooks. I therefore (vibe)coded a HTTP endpoint on the Home Assistant side which can be directly triggered by the 2N devices, including digest auth. It basically mimics the IP relays also sold by 2N. I'm still evaluating if I keep it as a separate custom component for now or if I spent the effort trying to merge it in one of the 2N components. Main advantage would be to make it show up as a single device entry in the UI.

Anyhow, thanks again for your reply and your efforts making the 2N ecosystem more accessible.

[cbergmann]

Hi, thanks for mentioning me directly.

I indeed worked on py2n and also @Neffez fork of helios2n-hass. It is currently at a stage at which I can do everything with the integration that I want to do. Mainly because I can get the events from the 2n device and call any 2n API via a home assistant service. I also think that the integration should be more beginner friendly. Mainly some of the features should be exposed by HA entities. For example the relays could be switches and some of the information available via the api could be sensors. This is only a hobby for me (as for most of the community) and therefore I don't think that I will spend much time in adding these additional features unless I need them for myself.

Unfortunately it seems that the original @SVD-NL repository is abandoned and if someone wants to use this branch of development I would currently recommend @Neffez fork.

I am interested in hearing your opinion and requirements and I also think it would be worthwhile to work together to create one google good 2N integration.

Kind regards
Clemens

[cbergmann]

One more addition: I have not looked deeply at your @moritzj29 fork of the integration. Maybe I should do this and @Neffez and you could somehow arrange to merge these development trees. If you need help in this idea I am willing to invest some time.

[cbergmann]

@moritzj29: I looked into your additions to py2n. Unfortunately on your fork the issues seem to be disabled and I found no direct way of contacting you. I hope all of your are fine with me using this thread for that.

I find the addition of digest authentication very interesting. Is there a particular reason why you chose to implement digest authentication yourself and not using the functionality already available in aiohttp?

[moritzj29]

Hi @cbergmann thanks for your reply! I just enabled the issue tracker, so we can also follow up there directly. Currently my fork is still heavily work in progress... I'm also no professional developer, especially when it comes to Home Assistant, so most of the stuff is heavily AI assisted. Currently I'm still in the process of verifying and refining. So thanks for the hint on aiohttps DigestAuth feature, that looks very reasonable.

As soon as I feel comfortable with one or the other feature/fix, I will create a clean, scoped PR. Otherwise review is too much effort for the maintainers, I completely understand that.

Mainly because I can get the events from the 2n device and call any 2n API via a home assistant service.

I should definitely look into this event bus feature, since this is what I missed most. But if I get it correctly it is still based on polling, right?
edit: ok, thats absolutely what I was looking for... could have saved me some effort on this relay emulator :D

[Neffez]

Hi, I merged @cbergmann changes into my fork at https://github.com/Neffez/helios2n-hass , I also had to do a fix for the config flow. It's available as v0.4.1

[moritzj29]

@Neffez thanks for the feedback! Since your branch will be the target for any PR ;), would you consider opening the issue tracker? I think it makes no sense to continue discussing a different integration here, neither at original SVD-NL repo as it is stale. I'm facing some issues with entities becoming unavailable frequently and would like to hear if others also see that... Thanks!

@genka13 thanks for igniting this alignment with your work, let's see if it makes sense to join forces at some point. I think my2N integration is definitely a valuable addition.

[genka13]

Hi everyone, thanks for all the engagement and the great discussion — it's really nice to see this kind of movement in the 2N community!

A bit of background on my side: I have done several 2N hardware installations myself, so this project is very much driven by a practical need for better integration and connectivity with other systems.

---

@moritzj29 — Your relay emulator is an interesting approach! I'm currently using the official 2N and AXIS IP relays in production, and some of my setups are built around 2N Automation. For simple use cases like door openers, the extra Automation license can feel like overkill — even though it unlocks a lot of additional capabilities. So far, I have always licensed Automation, but I can see the appeal of a lighter solution.

One thing I'd keep in mind though: I expect relay communication to become more restrictive over time. AXIS has already introduced encrypted communication, and device configuration is now only possible through AXIS Camera Station. The open 2N API is something I really appreciate, but things are still evolving on that front as well.

I'll definitely take a closer look at your relay emulator — in some cases it could be a simpler alternative to solving things through Automation.

---

@cbergmann — Regarding a Google 2N integration: interesting idea, but I have to be honest — my experience with Google Home hasn't been great so far. Many devices are not supported, and some promised features have been delayed or never delivered. That's actually one of the main reasons I'm focusing on Home Assistant as the central platform — to bring everything together in one place and make it accessible for everyone.

With 2N Access Commander, there are even more possibilities for communication and data exchange that My2N currently doesn't offer — though 2N is actively working on expanding that as well. So there's definitely a lot of potential here.

---

Looking forward to seeing where this goes!

[cbergmann]

Hi, sorry for the confusion. That was a typo/autocorrect error. I wanted to write "to create one good 2N integration.". Sorry for not catching this. I am not using google home and am also not interested in using it. I am currently using home assistant with alexa but I am in the process of moving away from centralized services.

[genka13]

Hi @cbergmann, no worries — the autocorrect got us there 😄 But it actually turned out to be a good prompt to clarify the direction.

Fully agree on moving away from centralized services. I think with Home Assistant we're building on the better and more community-friendly platform — open, flexible, and not dependent on any single vendor's roadmap. That's exactly the kind of foundation a solid 2N integration deserves.