Cannot find any entities

[gurrier]

I'm having difficulty getting this working.

I've got two sensors in TTN v3 which are confirmed as working in that console. I've added the integration for persistent storage to each of the Applications in TTN console for those sensors. I've created an API key for HASS to access those two applications.

When I install and configure this integration in HASS, it all looks good and the two devices show under the configuration of the Integration.

However, I do not see anything in the logs about the integration nor any device or entity relating to the two sensors.

BTW, I do see the data for these sensors displaying in Cayenne Cloud so that verifies the basic connectivity and approach using the API Keys.

Hoping you can give me a pointer to what I should be looking for.

[gurrier]

The log error I am seeing is this...hoping someone can point out if/where I might be going wrong.

Logger: custom_components.thethingsnetwork Source: custom_components/thethingsnetwork/TTN_client.py:204 Integration: The Things Network (documentation, issues) First occurred: July 28, 2022 at 4:00:51 PM (1120 occurrences) Last logged: 10:46:38 AM

TTN entry without result: {'error': {'grpc_code': 3, 'http_code': 400, 'message': 'error:pkg/auth:token (invalid token)', 'http_status': 'Bad Request', 'details': [{'@type': 'type.googleapis.com/ttn.lorawan.v3.ErrorDetails', 'namespace': 'pkg/auth', 'name': 'token', 'message_format': 'invalid token', 'correlation_id': '5e761b72f2c94409993f1eef28cddd0a', 'code': 3}]}}

[gurrier]

Could it be that the servers are for Australian except the Identity server which is EU?

[angelnu]

@tmugan - the URL is hardcoded to the EU provider currently - it can be changed at https://github.com/angelnu/home_assistant_thethingsnetwork/blob/3e0f15c0b674ea930838f19ef772e92921740bb9/custom_components/thethingsnetwork/const.py#L16

I would need to add a selection of the URL but for the time being you need to change it manually after checking out the code.

[gurrier]

the URL is hardcoded to the EU provider currently - it can be changed at

@angelnu Thanks for the response. I have tried to change that to "au1.cloud.thethings.network" to no avail in a dev environment. I discovered that there are servers for the au region but that eu1 is still used as the authentication server in AU.

See this page if you select Australia from the dropdown this link

I presume that somewhere, there are calls made to both the eu1 and au1 servers as a result. Do you have any thoughts on how to deal with that?

Cheers.

[angelnu]

The adapter does not authenticate but use a bearer token so it should not need to use the Europe URL. The only API call is at https://github.com/angelnu/home_assistant_thethingsnetwork/blob/8be8e5b24754f087aa76ec7b9df4446bbc960168/custom_components/thethingsnetwork/TTN_client.py#L361

Is the error you get after changing TTN_API_HOSTNAME the same as before (invalid token)?

Another thing to check is what the URL is for the storage API in Australia.

[gurrier]

Is the error you get after changing TTN_API_HOSTNAME the same as before (invalid token)?

Yes, Invalid Token is still the error. I'm stumped now, I've tried prepending the bearer token with NNSXS. but that made no difference. I have a single device in the application and have configured the Storage API Integration for that application.

I'm testing now from command line with variations of the curl command below (XXX as the Application API key for HASS with ALL rights granted. temp-humidity-dragino-lht65 is the Application ID)

curl --location \ --header "Authorization: Bearer NNSXS.XXX" \ --header 'Accept: text/event-stream' \ --header 'User-Agent: my-integration/my-integration-version' \ 'https://au1.cloud.thethings.network/api/v3/as/applications/temp-humidity-dragino-lht65/devices/dev1/packages/storage/uplink_message?last=24h&order=received_at'

[gurrier]

Ok, I deleted the API key and created a new one. This time the API key actually had the format NNSXS.XXX.XXX In the curl command it did not throw an error (that's encouraging) but returned nothing in the command line. I'll try now in the custom build of your integration with the au1 URL.

[gurrier]

Not managed to get it working. Should I be receiving a response with the curl command above?

[angelnu]

if your device sent an update in the last 24h it should. If not you might increase the time

[gurrier]

@tmugan - the URL is hardcoded to the EU provider currently - it can be changed at

https://github.com/angelnu/home_assistant_thethingsnetwork/blob/3e0f15c0b674ea930838f19ef772e92921740bb9/custom_components/thethingsnetwork/const.py#L16

I would need to add a selection of the URL but for the time being you need to change it manually after checking out the code.

In the end, I think the issue is just that the EU is hard coded. I managed to get a successful response from the curl command line. Do you have any plans to allow AU1 to be a selectable field in the config? @angelnu

[gurrier]

Just following up on this to see if there are any plans to offer AU support through this or a fork? Thanks.

[angelnu]

This custom integration is deprecated as it has been integrated into the core HA since 2024.6.

Please migrate.

[gurrier]

Hi @angelnu I never did manage to get any TTN entities to be visible in HA back when I lodged this issue.

I saw recently that the integration was being brought into HA Core so I removed the old integration and installed the new one. I have added two TTN Applications in HA (now called "Hubs" in the TTN integration) but do not see any devices or entities.

I note that you have in your documentation that location and binary sensors are not yet supported. Is this my issue?

[angelnu]

When you register TTN applications with the new official integration it is possible to set a different API url as the default EU one.

If you still see no entities the first check should be to ensure there are application decoders. If this part works and you still do not get entities, please raise a bug at the HA core project - it will be assigned to me there.

If the decoded payload only has boolean entries (binary sensor) then yes, you would not get those for now.