Reversed setup (GSM dongle in Home Assistant, SIM in car), Nabu Casa webhook too long (208 vs 128 chars), and question about periodic refresh approach

[Zulgrid]

Hi, and thanks for an excellent project!

I’m running a somewhat reversed setup, and I’m hoping someone here has insights or recommendations:

I have a GSM dongle connected to my Home Assistant server with an unlimited-SMS plan.

In the car, I’m using a SIM card with a cheap pay-as-you-go plan.

The issue is how to trigger the SMS commands from Home Assistant. I’m behind carrier-grade NAT and don’t have the option to open a port to the internet. I tried setting up a webhook via Home Assistant / Nabu Casa, but the generated webhook URL is 208 characters long, while the opencarwings web interface only supports 128 characters.
So that webhook method is not usable in my case.

As a workaround, I’ve configured opencarwings as “own device” and I’m triggering actions (refresh, start/stop AC, start charging) through REST calls from Home Assistant. This works, but not very reliably yet.

My main question is:
Are there any obstacles or pitfalls I should be aware of if I use the following approach?

Every 15 minutes, Home Assistant sends a refresh request to the opencarwings server

And at the same time sends an SMS to the car

I’m not sure whether this dual approach (server refresh + SMS trigger every 15 minutes) could cause unexpected issues or conflicts within opencarwings.

Thanks in advance!

[developerfromjokela]

Hi, and thanks for an excellent project!

I’m running a somewhat reversed setup, and I’m hoping someone here has insights or recommendations:

I have a GSM dongle connected to my Home Assistant server with an unlimited-SMS plan.

In the car, I’m using a SIM card with a cheap pay-as-you-go plan.

The issue is how to trigger the SMS commands from Home Assistant. I’m behind carrier-grade NAT and don’t have the option to open a port to the internet. I tried setting up a webhook via Home Assistant / Nabu Casa, but the generated webhook URL is 208 characters long, while the opencarwings web interface only supports 128 characters.

So that webhook method is not usable in my case.

As a workaround, I’ve configured opencarwings as “own device” and I’m triggering actions (refresh, start/stop AC, start charging) through REST calls from Home Assistant. This works, but not very reliably yet.

My main question is:

Are there any obstacles or pitfalls I should be aware of if I use the following approach?

Every 15 minutes, Home Assistant sends a refresh request to the opencarwings server

And at the same time sends an SMS to the car

I’m not sure whether this dual approach (server refresh + SMS trigger every 15 minutes) could cause unexpected issues or conflicts within opencarwings.

Thanks in advance!

Hi!

I can increase the webhook url length, but is the webhook accessible on internet?

And there's no issue using the "Manual" option, so you'll be in charge of sending the sms like you do now with the gsm modem. As long as SMS gets delivered one way or another :)

But ideal would be to use the webhook, so you can also send commands via mobile app or use timers.

The only thing to keep in mind is that doing data refreshes too often could drain the 12V battery. I've used auto refres for few months with an interval of 1 h and then 15 min while charging. So far no issues with 12V battery

[Zulgrid]

Hi, and thanks for the quick reply!

Yes, the webhook is accessible from the internet .The URL works fine externally, but I can’t fit it into the field in the web UI.
If you’re able to increase the allowed webhook length, that would solve the issue for me.

I fully agree that using the webhook would be the ideal setup, especially for mobile app control and timers — so I would definitely switch to that if the field can accept the longer URL.

Thanks also for the note about refresh frequency and the 12V battery. I vil change my update frequency.

Thanks again for your help — much appreciated!

[developerfromjokela]

Hi, and thanks for the quick reply!

Yes, the webhook is accessible from the internet .The URL works fine externally, but I can’t fit it into the field in the web UI. If you’re able to increase the allowed webhook length, that would solve the issue for me.

I fully agree that using the webhook would be the ideal setup, especially for mobile app control and timers — so I would definitely switch to that if the field can accept the longer URL.

Thanks also for the note about refresh frequency and the 12V battery. I vil change my update frequency.

Thanks again for your help — much appreciated!

Hi. Webhook field should now fit your link :) Increased it to 512

[Zulgrid]

Perfect - thank you :-)