Skip to content

Comments

fix: use GraphQL API for smarthome list#3

Open
BurtTheCoder wants to merge 2 commits intobuddyh:mainfrom
BurtTheCoder:fix-smarthome-list-graphql
Open

fix: use GraphQL API for smarthome list#3
BurtTheCoder wants to merge 2 commits intobuddyh:mainfrom
BurtTheCoder:fix-smarthome-list-graphql

Conversation

@BurtTheCoder
Copy link

The /api/phoenix endpoint returns HTTP 299 with empty response. Switch to /nexus/v1/graphql which properly returns smart home devices.

Changes:

  • Use GraphQL endpoint POST /nexus/v1/graphql
  • Update response parsing for GraphQL structure
  • Fix applianceTypes to handle array instead of string

Tested with 135+ devices including lights, cameras, switches, contact sensors, motion sensors, and thermostats.

orie added 2 commits January 25, 2026 17:47
The /api/phoenix endpoint returns HTTP 299 with empty response.
Switch to /nexus/v1/graphql which properly returns smart home devices.

Changes:
- Use GraphQL endpoint POST /nexus/v1/graphql
- Update response parsing for GraphQL structure
- Fix applianceTypes to handle array instead of string

Tested with 135+ devices including lights, cameras, switches,
contact sensors, motion sensors, and thermostats.
Change ControlSmartHome endpoint from pitangui to alexa.amazon.com
and use /api/phoenix/state instead of /api/behaviors/entities/appliances/state
Copy link
Owner

@buddyh buddyh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for tackling this — the /api/phoenix returning 299 is a real issue. A few things need addressing before this can merge:

Blocking

1. Nil pointer panics in response parsing

item.DisplayCategories.Primary.Value will panic if either DisplayCategories or Primary is nil. Needs defensive checks:

if item.DisplayCategories != nil && item.DisplayCategories.Primary != nil {
    device.Type = item.DisplayCategories.Primary.Value
}

Same applies to result.Data.Endpoints.Items — if the GraphQL response structure differs from expected, the whole thing crashes silently or panics.

2. EntityID overwrite logic is unclear

device.EntityID = item.EndpointID  // set here first
// ...
if item.LegacyAppliance != nil {
    device.EntityID = item.LegacyAppliance.EntityID  // then overwritten here
}

If these IDs differ, which one does ControlSmartHome() actually need? This needs a comment explaining the precedence, or validation that they match.

3. Control endpoint silently changed

// Before:
_, err := c.request("PUT", "/api/phoenix/state", payload)

// After:
_, err := c.requestAlexa("PUT", "/api/phoenix/state", payload)

This switches the control endpoint from pitangui.amazon.com to alexa.amazon.com. If the control API doesn't exist at that host, all smart home controls break. Can you confirm device control still works after this change? This should probably be a separate PR or at least called out explicitly.

4. Reachable hardcoded to true

device.Reachable = true  // always true unless NetworkState parses

If LegacyAppliance is nil or NetworkState unmarshaling fails silently, every device appears online. The old endpoint returned reachability directly — this is a regression.

Questions

  • What's the source for the GraphQL query structure? (mitmproxy capture, official docs, etc.)
  • Did you test device control (not just listing) after this change?
  • Is the HTTP 299 a permanent API deprecation or could it be transient?

The approach is sound — just needs hardening before it's safe to merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants