CAME Connect - New Custom Integration

Hi all,

I’ve created an unofficial Home Assistant integration for controlling CAME gates/automation systems via the CAME Connect cloud.

Features

  • Control your gate with a cover entity (open / close / stop)
  • Status sensors (connection state, last update)
  • Full UI config flow (no YAML)
  • Adjustable poll interval

Requirements

  • Home Assistant 2023.9+
  • CAME Connect account + Device ID
  • Client ID & Secret (extracted from the CAME web app)

Installation
Available through HACS as a custom repository.

:point_right: Full instructions, setup guide, and troubleshooting are here:
[GitHub - sdeagh/came_connect: Custom Home Assistant component for CAME Connect]

Feedback and testing on different CAME boards is very welcome!

Edit:
I’ve just seen a similar “add-on” for came connect gates (https://github.com/yashijoe/hassio-cameconnect) I’ve reached out to the author to see if we can combine forces.

5 Likes

Hello,
Thanks a lot for your project which interess probably lot of peaple like me !

I’ve config my installation in HA but when I want to change the Redirect URI and when i clic on the cog icon i have this message :“500 Internal Server Error Server got itself in trouble”.

For information I use CAME Connect for the connection to come connect

Do you know why ?
Cheers
Guillaume

Hi,

not sure what happened there. If you re-download v1.0.1 from HACS then restart HA it should be working.

Cheers

Hello,

thank you for your fantastic work. Just got my came gate/automation installed with Came Key Wifi Gateway. What a surprise it was to see that the custom integration was just developed 6 days ago! what are the chances :slight_smile:

I followed the installation instructions in github, and managed to configure the integration. I can see my Gate available in the integration UI, but…
I see only Sensors - i cant execute any actions. On top of that, it looks like only “Gate Hub Online” entity is showing correct value - connected. Everything else is just “unknown” or 0% for gate position (and it is not changing). The only other entity that is reacting, kind of, properly is “Gate Hub Last Seen” which, at least looks like, is showing the last time i interacted with the gate.

Any ideas what it be wrong? Is it “me” or there is a bug in the integration?

Btw. I might be wrong but looks like there is also inconsistency in the documentation.
for the redirect_uri parameter, it says that the default is Error - but in fact it is not. The default is CAME Connect. So i had to explicitly switch to Error , but… is that the correct value? the actual URL of the cameconnect is https://cameconnect.net. Looks like https://beta.cameconnect.net got decommissioned recently with the release of the new UI, and Error doesn’t seem to be working at all - but maybe that is expected.

One more time, thank you for your effort in developing the plugin and, hopefuly, solving my problems :slight_smile:

Hi Michal :wave:

Thank you so much for the kind words and for testing this out — I really appreciate it!

Just to set expectations: this is actually the first Home Assistant integration I’ve ever written. At the moment I can only test against my own gate setup, so I don’t yet know how it behaves with other CAME hardware or gateways.

I’ve made a lot of changes today, so it would be best if you could try again tomorrow with a completely fresh install of the integration. I plan on releasing in about 1 hour from now after some testing.

Right now, I’d call this very much a beta product. It works for me, but there are likely still bugs, inconsistencies, and missing features. Any help from others in testing, reporting issues, and suggesting improvements is hugely appreciated — that’s the only way we can make this stable and useful for more people. :pray:

Thanks again for giving it a go, and please keep the feedback coming!

1 Like

Sorry for posting again!

Actions are now available in the integration screen. You can also call services against the device — currently open, close, and stop.

I’ve been going round in circles trying to figure out the best polling strategy without putting too much load on the CAME servers. At the moment I’ve implemented:

  • Idle poll: every 5 minutes when nothing is happening
  • Motion poll: every 2 seconds once you trigger an action (e.g. open)
  • Motion poll timeout: after 2 minutes of rapid polling, it falls back to the 5-minute idle poll, even if the gate still hasn’t fully closed

These are all configurable in the options (cog wheel) screen - to a degree.

I’m very conscious about not spamming the CAME servers, but I’d love to hear your thoughts (and anyone else’s!) on whether this seems reasonable or if there’s a better approach.

Thanks again for your kind words and support — it really helps!

1 Like

thank you very much for the quick response!

Of course i understand that this is not a professional-grade extension and that, most probably, you a re implementing it in your free time which, as most of us, you don’t have that much. So i dont expect everything to work out of the box, and i am happy to help at least with testing to fix al/some of those issues.

To clarify, my hardware is:

  • Came Key Wifi Gate (FW: 1.1.26)
  • Gate Automation: ZN7 (FW: 2.6.4)

After downloading version 1.1.0 of the integration i see the progress in a good direction, but still not everything is working.

  1. I do see the actions right now
  2. most of the sensors are still in “unknown” status, except for:
    2.1 Gate Hub Last Seen
    2.2 Gate Hub Online

When i press on the “open” button the gate actuaklly starts to open but the close button is always disabled (as visible on the screen). I guess it is due to the fact that the integration doesnt know if the status of the gate, and the Default gate position is always “0%” so it assumes that it is always fully closed.

I had a look at the cameconnect UI to look at what endpoints are reporting on the gate status in my case and it looks like it is this one:
https://app.cameconnect.net/api/devicestatus?devices=[DEVICE_ID]

Looks like the Data->States->Data property reports on what is happening with the gate. Looks like the first item in that array is the code for the movement and the second one is the position of the gate

  • 17 - closed
  • 32 - openning
  • 19 - partially open
  • 16 - fully opened
  • 33 - closing

I guess you know what already, but maybe it is different for my hardware than yours - that would explain why the sensors are not working.

    "Success": true,
    "Data": [
        {
            "Id": DEVICE_ID,
            "Configured": 0,
            "ConfiguredLastUpdate": "2025-09-11T19:34:58.000Z",
            "Online": true,
            "Limbo": false,
            "Autodiscover": 0,
            "States": [
                {
                    "Data": [
                        17,
                        0
                    ],

edit: just had a look at the source code and I do see that you mapped the same values as constants.

Hey Michal — huge thanks for the detailed write-up and for testing :+1:

Quick update: I’ve just pushed v1.2.0, which is a big rewrite. The integration now runs WebSocket-first (like the CAME web app) so state changes are pushed to HA in real time. That means:

  • No periodic polling anymore (except a single /devicestatus fetch at startup to seed state).
  • Live updates for Open/Opening/Closing/Closed/Stopped (we now map phase 19 as Stopped).
  • Entities (phase/position/moving) are populated immediately by the initial seed, and then kept in sync by WebSocket events.
  • The Close button shouldn’t be stuck disabled—HA knows the phase/position from the seed + WS events.

Your observations about States[2].Data = [phase, percent] are spot-on and exactly what v1.2.0 uses under the hood.

What to do

  1. Update to v1.2.0 in HACS (or pull latest).
  2. If you were on an older build, I recommend: Remove the integration → Restart HA → Add it again (clears old options).
  3. In Options, you’ll now only see:
  • Redirect URI (default https://app.cameconnect.net/role)
  • WebSocket URL (default wss://app.cameconnect.net/api/events-real-time)
  1. Open/close the gate once (from HA or the CAME app) and confirm the HA entities move through Opening → Open → Closing → Closed.

If something still looks off

Please enable debug logging and share the snippets around an open/close cycle:

logger:
  default: warning
  logs:
    custom_components.came_connect: debug
    custom_components.came_connect.api.ws: debug

You should see lines like:

WS connected
WS TEXT: {... VarcoStatusUpdate ... "Payload":[32, 58]}  # Opening 58%

If you don’t get those VarcoStatusUpdate frames:

  • double-check Redirect URI matches the site you log into (usually https://app.cameconnect.net/role);
  • and that WebSocket URL is the default above.

Hardware notes

I’ve been testing on a ZLX24SA; your ZN7 reports the same phase codes (16/17/32/33/19), which we now handle uniformly. If your device ever emits a variant, the logs will show it and I’ll add support.

Really appreciate you helping test this—v1.2.0 should be snappier and more reliable. Let me know how it behaves on your ZN7!

1 Like

Hello!

I seriously can’t stress enough how grateful I am for your work!
Just upgraded to 1.2.0 (without removing the integration) and looks like all is working now. I do see the proper status of all entities and I was able to open and close the gate!

It is 10:41 PM right now in Poland so I will do more testing tomorrow during the day. But this release looks very promising!! Moving to web sockets is also a great addition, push will be so much better in this case than a pull! I really appreciated your concern about pulling cameconnect too often from the start (they might block us due to that)!!

1 Like

Hi!
I managed to get it up and running without any errors, but my Gate doesn’t seem to react to any HA buttons. I assume it’s because my Garage Door controller is a simple Input/Output board soldered into my Garage Door Controller?

I’ve tried adding both “Naped” Device ID and “Brama” Device ID - no reaction.

If you had some time and/or need any more information - let me know if I can provide anything!

I managed to brutally “fix” this for myself and changed the api from /automations/ to /multiio/ in “send_command” function and it works for now.

No problems here, what is the error message?

Hi,
firstly great job is one year that I search if somebody was able to connect came device, now we can do thanks a lot!
But I have a big issue that I try to solve without success…I’m not a developper and I try verif difficult to find the clientID and relevant secrete…I try to open the developper and find the “long-base64-string” but the result of the decoding Base64 do not show “clientId:clientSecret” :sob:

Hi,

If you check closely you will see a load of numbers and letters followed by : then more letters and numbers once you’ve run it through the decoder.

Example:-fkdenejknjr3343refd23:mkwncjkence6ce6c6e6ce66ec7e77ce7c7e7ce7c7ec7dvrgbrgf7d

Split these without the : and you have your ClientID and ClientSecret values.

Thanks, but under the autorization “Basic” I have 388 characther… and no one :… :sob:

try following those steps:

  1. go to: https://www.cameconnect.net/

  2. open web developer tools, and go to network tab

  3. login with you credentials

  4. in the network tab, search for auth-code call. The URL will include the client_id - one of the values you need.

  5. click on that call, and in “Headers” tab scroll down to “Authorization” header

  6. copy the value of the header WITHOUT “Basic” part. Most probably this will end with == - but not necesairly.

  7. that value is base64 encoded value of your client_id AND a secret. So you need co decode it. for that you can use, for example, this website:
    Base64 Decode - Online Tools

  8. put the value in the “input” are, and the output will show values something like:
    jksdnfkasldkfas:kasjwenbdfajsndaskndmakmsdkadmaksdasdasdd

i.e. 2 values seperated by :. The first value is your client_id (you can confirm that by comparing against the value from step 4), and the second one is the secret you are looking for.

Hope it helped. if not - let me know.

1 Like

Yep!! Resolt, thanks a lot, I understood where I made a mistake!!!
Using a different application for decoding I could not find the “:” and does not work.
Now I just have a last question, I have two device for each gate, one is the key and one is the panel, which I need to connect?

1 Like

I’ve installed this today and just came here to say the integration is amazing and solves the reason why I started with HA, having the phase of the gate is perfect!

Thank you so much for developing it.

I agree! it is amazing that you can integrate almost anything with Home Assistant.

1 Like

I had the same doubt when I was initially using the integration. I dont remember exactly - but I am 90% sure that you should see the device ID of the actual gate opener, not the Key/Gateway.

1 Like