[zerog2k]

It’s like the old saying, if the product is free, then YOU are the product.  In this case, they are claiming that the device is sold at cost, so essentially subsidized, meaning again that you and your data is the product/ business model.

However, looking at these devices, the hardware BOM is probably 30-40 bucks at most, and they sell for like 100. This is before the engineering and supporting costs around developing hardware. The real cost is probably the cloud services bill around running their platform, plus the cost of developing and maintaining the app. So maybe “at cost” is believable, but if you don’t run on their app or cloud platform, then it kinda takes those parts’ cost out back of the equation. So I seriously doubt they would ever entertain a cloud-free operation, as they would lose the data access, which I feel is where the value is from

 

• This reply was modified 3 years, 1 month ago by zerog2k.

[zerog2k]

Exactly what Alex said. This is a business story for you!

The geeks and nerds who play with this stuff are your free advocates to the less techie friends, family, and coworkers who would buy into more of your products & services.

[zerog2k]

another angle might be to add all the amazon root CAs listed here

https://www.amazontrust.com/repository/

to the ca cert file you pass to mosquitto configuration (in addition to whatever trust bundle is being passed now, which contains your server cert – I believe it will need to contain a trusted ca for both server and client certs to be internally happy)

 

[zerog2k]

The devices seem to be based around Amazon IoT platform, which provides frameworks and tooling to handle a number of things like device provisioning/registration, including issuing client certificates, app/user identity with Cognito, and providing mqtt/http service endpoints to collect data and establish communication channels with devices.

The endpoints and ports you describe are most likely amazon iot mqtt endpoints. (Yes they will have strange names, as they are generated by AWS for some given service instance.) For more info see: https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html

The devices are certainly using client certs issued and signed by some amazon ca or similar, see: https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html

Usually, there is some way to make a TLS server ignore cert validity of client (for testing purposes ;), but in this case, I’m not finding such an obvious option: https://mosquitto.org/man/mosquitto-conf-5.html

 

 

[zerog2k]

Do you have an email which a party wishing to make a responsible disclosure can correspond with your team?
This public forum is probably not appropriate for reporting possibly sensitive issues.

Regarding the responsible disclosure policy, part of it is about establishing a reporting process and commitments to prioritize fixing issues, but also about assurances that responsible disclosures made in good faith will be treated in good faith, and that the reporter would not be penalized.

It’s not surprising that some companies react to be being notified about potential security issues by threatening the messenger with legal action – which has a chilling effect on responsible disclosure. The policy just helps set expectations on all sides.

 

[zerog2k]

It’s mqtts protected w/ mTLS (using a client certificate).

It’s AWS IoT MQTT implementation:
https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html

Anyhow, it should be totally possible with ESP32 or even ESP8266 to expose simple, local json/rest api, or be able to configure unit to additionally publish to mqtt server of user’s choosing. Of course the devil is in the details of how you expose, validate, manage, and secure this configuration lifecycle to users, but it’s all possible. Likely (obviously) just low priority by Emporia product/dev teams.

Alternatively, they could expose a proper “cloud” api, i.e. developer apis. But this would also be some amount of work to manage user api keys, protection (security, rate limiting, etc), configuration, etc.

Again, some amount of work, but in this day and age, any type of “cloud” service like this, having such an api and user access to their data programmatically (for allowing integration with other cloud/local services, e.g. home automation, etc) is considered “table stakes” to put it in product/biz-speak.

 

[zerog2k]

another +1 for real options on direct access to our data:

1. also send the data to mqtt server (from local device preferred)

2. also send the data to influxdb server (from local device preferred)

3. pollable cloud api (less desirable for me, but still acceptable if it’s high-enough resolution, e.g. 5-10s)

Overall, I would think giving users option to additional have the device report to local mqtt and/or influxdb could be implemented comparatively quickly and easily, and probably cover 90% of the “home automation” power-users like myself and several others here. (Perhaps the trickiest part could be how to pass  configuration [securely] to device; I’m hand-waving a tad, but seems like much easier than the littany of concerns with architecture, cost, reliability, security, etc around exposing and maintaining a public-facing user api.)

 

• This reply was modified 4 years, 6 months ago by zerog2k.

[Author]

Posts