Hot off the presses folks!
Unable to use.
Just paid for a Noonlight account; when I try to install the Noonlight Enhanced HACS component, it a) stomps on my Noonlight integration, and b) makes the "Noonlight switch entity" unavailable.
What am I missing?
Noonlight Enhanced is an integration itself using v2 of the Noonlight API, it replaces the original Noonlight Integration which uses the v1 of the API, you can't have both, one or the other. I would suggest you uninstall both, restart HA, then install just one of them.
Just did that, thanks.
What I noticed was it got rid of the switch that "phones home" (I assume?) to Noonlight. Instead, I see in the Developer Tools section, the ability to make action/service calls.
Is that the expected behavior?
Thanks again!
1 Like
Good catch on the switch. The original Noonlight integration used a switch-style entity as part of the alarm trigger flow, but Noonlight Enhanced is now intended to be service/action driven through noonlight.create_alarm.
I kept a lightweight informational entity so the integration still appears cleanly in Home Assistant's Devices & Services UI, but turning it on no longer dispatches an alarm. It now just creates a Home Assistant notification explaining that dispatches should be created through the noonlight.create_alarm action/service.
That action/service is the supported path because it allows automations to include alarm cause, operator instructions, sandbox/production routing, endpoint overrides, and other dispatch metadata.
I also updated the README and comments to make this clearer. (So please redownload and you should be good to go.)
1 Like
Will do. Thanks again!
1 Like
Trying to figure out how to test.
When talking to Noonlight directly to setup an account, they said I had to get a "consumer account" (vs a developer account). Therefore, I've got no idea how to get a developer account. (I've reached out to them as well asking the same question).
In the section titled " Simple Sandbox Example," you mention:
server_token_override: YOUR_SANDBOX_SERVER_TOKEN
What is this? Where do I find it, and/or how do I create this?
Thanks again!
No, you can do it all online, you don't need to talk to anyone. For purposes of this you are from their point of view a developer because you are using code to call their API. Go to noonlight.com, click on "developers'" on the top, then there is a screen that tells you how to get a token. On the left is all the documentation you need about how everything works, and any gaps or items you do not understand, google (which not does not just search but has ai built in to understand your questrions) or any other chat engine can help walk you through what ever you need for any specific questions
Thanks @KruseLuds for taking the time to making this integration. I was thinking it would be great to have an integration that uses noonlight's V2 API.
When setting up the integration it asks for client ID and client secret. Where do we get these fields? After creating a developer account on noonlight they only give me a server token field and webhook secret fields. Are those the client ID and secrets?
The current integration was originally built around Noonlight's OAuth-based workflow and expects a Client ID and Client Secret during configuration.
If you're only seeing a Server Token and Webhook Secret in the Noonlight developer portal, you're likely looking at the newer Dispatch API v2 credentials rather than the older OAuth application credentials.
In Noonlight's newer developer workflow:
- Server Token = used for authenticated server-to-server dispatch requests
- Webhook Secret = used to validate inbound webhook payloads
- Neither of those is the same thing as a Client ID or Client Secret
The current version of the integration still has some legacy configuration fields from the original integration, although Noonlight Enhanced adds support for server token override workflows when using the newer API patterns.
Here is a link to the readme for the original (v1 api) integration, which explains in the "initial setup" setup how to originally get the Client ID and Client Secret:
I couldn't find a way to get the v1 auth and with their new v2 auth, though you can get prod token you can't actually use it until you go through some partner review with them or something.
Realized that rather than sign up for develoepr account, I needed to sign up for a customer account through the konnected signup link which uses the v1 auth. That is linked in GitHub - konnected-io/noonlight-hass: HomeAssistant integration for Noonlight · GitHub.
1 Like
I got prod working now without a service token set but using the v2 dispatch API.
@KruseLuds Were you able to get webhooks working with production? It seems like it is tied to using the service token, which doesn't seem supported in production?
I haven't done extensive testing of production webhooks with a Service Token.
My production setup is using the v2 Dispatch API without a Service Token configured, and webhook functionality has not been a major part of my workflow, so I can't confidently say whether Noonlight requires a Service Token for production webhook delivery.
If you've already confirmed that production dispatches are working without a Service Token, then you may be exploring an area I haven't personally validated.
For my own use case, dispatch creation has been the primary focus, and since that is working reliably I haven't spent much time investigating alternative authentication or webhook configurations beyond what was needed to get the integration functioning.
@amosyuen FYI I have updated the readme to clarify your question regarding the tokens, look at the additional verbiage for "Credential Note" under Initial Noonlight Setup - thank you for pointing that out!
Migrating from the Konnected implementation to this one and I'm able to get the production alerts working but it appears to be using the V1 endpoints as additional data isn't being sent. Also not having any luck with the token override and being able to debug calls. I'm using the same id/secret as the original integration. Curious what I'm doing wrong.
EDIT: Update that I got the developer tools working - my phone number was an invalid format. Still not able to get a production call against the v2 API.
Trying to do a test this is the call in dev tools:
data:
service: fire
instructions: This is a test do not dispatch
alarm_cause: TESTING - Smoke detector detected smoke
server_token_override: *****
api_endpoint: https://api-sandbox.noonlight.com/dispatch/v1
Glad you got Developer Tools working. The phone number format issue can definitely block the call before the dispatch request gets very far.
A couple of notes:
For sandbox testing with a server token override, make sure you are using the service fields exposed by this integration. The endpoint field is api_endpoint , not api_endpoint_override .
Example:
service: noonlight.create_alarm
data:
service: fire
instructions: This is a test do not dispatch
alarm_cause: TESTING - Smoke detector detected smoke
server_token_override: YOUR_SANDBOX_SERVER_TOKEN
api_endpoint: https://api-sandbox.noonlight.com/dispatch/v1
For production, my working setup uses the original OAuth/Konnected credential flow with the configured Client ID and Client Secret. I have not validated production dispatch using a production Service Token override, and I would not assume the sandbox server-token pattern applies to production.
The v2-style extended fields such as alarm_cause and instructions are intended to be sent through the noonlight.create_alarm service/action. If production is still behaving like the older v1 path, the first things I’d check are the exact endpoint being used at runtime and whether the automation/service call is passing api_endpoint correctly.
I'm able to get the sandbox to work properly calling the Noonlight.create_alarm service and can make production calls as well. It doesn't appear to pass in the service information (fire, police, medical) or any of the other information. This is the test I made
service: noonlight.create_alarm
data:
service: fire
instructions: This is a test do not dispatch
alarm_cause: TESTING - Smoke detector detected smoke
How would I track down which API it's calling, I'm not seeing that info in the logs
That's helpful information.
One thing I notice is that your production test doesn't include an api_endpoint override, whereas your sandbox test did.
If api_endpoint isn't provided in the service call, the integration falls back to the endpoint configured in the integration settings. That could explain why you're seeing different behavior between sandbox and production.
Could you check which API endpoint is configured in the integration settings?
I'm trying to determine whether the production call is using the configured endpoint or whether something else is preventing the additional fields from being sent. That will help narrow down whether this is an endpoint-selection issue or something else in the request path.
What is the production API endpoint for V2 dispatch?
The GitHub specifies https://api.noonlight.com/platform/v1 but that looks like it is the version 1.
It also specifies for the sandbox https://api-sandbox.noonlight.com/dispatch/v1. That is the link that appears in the official noonlight documention for V2.
Which makes me think that the production v2 endpoint should be https://api.noonlight.com/dispatch/v1
Am I right?
It’s a little confusing because Noonlight’s endpoint naming doesn’t line up with the Dispatch API version.
The integration uses:
Production
https://api.noonlight.com/dispatch/v1
Sandbox
https://api-sandbox.noonlight.com/dispatch/v1
Those are the endpoints I’ve successfully tested with the Dispatch API v2 request payload (additional fields such as alarm_cause and instructions), even though the URL path still contains /dispatch/v1.
The /platform/v1 endpoint shown in the repository is not the dispatch endpoint. It’s used for the OAuth/token flow and other platform APIs, not for creating dispatches.
So yes, your conclusion is correct: the production dispatch endpoint is:
https://api.noonlight.com/dispatch/v1
despite the v1 in the URL. The version of the request is determined by the payload the API accepts, not by the URL path.