Emporia Community

Community Forum for Emporia

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 18 total)
  • Author
    Posts
  • in reply to: API to pull data #8107 Report Abuse
    wz2b
    Member

    Searching the binary for that string shows us a section where the words “ssid”, “emporia”, “password”, “emporia123” are found in close succession.

    Are you saying it attempts to connect to a local network named ’emporia’ as part of some debugging code, or as part of the provisioning process?  Maybe you’ve uncovered some factory test mode?

    If it isn’t a virgin device, does it still look for the ‘Emporia’ network on start-up?

    I’d still be interested in decoding the GATT message format, I’m just not very good at that kind of reverse engineernig.

    in reply to: API to pull data #7838 Report Abuse
    wz2b
    Member

    A small but vocal group of douchebags who have way too much time on their hands say what?

    I think that’s pretty harsh. ” You won’t get anywhere by beating Emporia up” would be a fair point.  But I think it’s a mistake to discount the advertising value of a small group of technical evangelists.

    in reply to: API to pull data #7694 Report Abuse
    wz2b
    Member

    These are good questions you asked.

    For my web server I use letsencrypt, so I tried starting mosquitto pointing toward the latest letsencrypt certificate and that worked – at least, i was able to pub/sub from a mqtts client without any errors.  However, that’s a legitimate certificate, so there’s still the possibility the vue is looking for something with a CN that matches the domain.  I wouldn’t THINK so though based on the wacky hostname, which looks like an aws auto generated host.  Or it could be looking for a specific certificate.  The answer to the question is that I’m not really sure and am trying to figure it out.

     

    Also, you are assuming that the VUE doesn’t use a client certificate to connect to the server, which would have to be signed by the server’s private key. Do you have any evidence that that isn’t the case?

     

    I think so.  I receive this log:

    OpenSSL Error[0]: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate

    There’s a little information out there about this message, but I’m not familiar with mqtts or tls to really understand what OpenSSL is trying to tell me here.  I interpret this to mean the vue2 is sending a client certificate but it doesn’t match any known CAs so it is rejected.  One thing I tried was forcing mosquitto to only accept v1.3 or later and this produced a different error message (invalid/unsupported TLS version).  So my conclusion based on that is that the Vue2 is indeed sending a certificate and it’s TLS v1.2.

    I wonder if there’s some way I can test this with something like ‘netcat -l’ but that accepts TLS.  I found something named ‘socat’ exists.  Maybe I will try that next, at least to see if there’s a way to tell it “Accept any certificate, just give me some logs to tell me what it’s trying.”

     

     

    in reply to: API to pull data #7683 Report Abuse
    wz2b
    Member

    Could the Vue2 be using a client certificate?  If that’s the case, I think my mosquitto doesn’t know to trust it … that’s what the error seems to indicate, anyway.

     

    in reply to: API to pull data #7681 Report Abuse
    wz2b
    Member

    I upgraded mosquitto and it changed:

    1624935763: New connection from x.x.x.x:52059 on port 8883.
    1624935922: OpenSSL Error[0]: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate
    1624935763: Client <unknown> disconnected due to protocol error.

     

    • This reply was modified 5 months, 1 week ago by wz2b.
    in reply to: API to pull data #7680 Report Abuse
    wz2b
    Member

    Redirecting through DNS was easy enough but mosquitto doesn’t like something.  I’m not super familiar with mosquitto so I set it up like this:

    certfile /etc/xxx/cert.pem
    keyfile /etc/xxx/privkey.pem
    port 8883
    protocol mqtt
    tls_version tlsv1.2

    The Vue2 is definitely trying to connect to it but something is failing, probably the TLS exchange.  Maybe the Vue2 is smart enough to check the server cert and make sure it’s valid?

    On startup, the Vue2 does three DNS queries

    • a2poo8btpqc3gs-ats.iot.us-east-2.amazonaws.com  this is the MQTT destination
    • fwsrv.emporiaenergy.com   this is probably to check for firmware upgrades
    • pool.ntp.org   network time server

    Not sure what’s with the wacky hostname, but the DNS response is a list of 8 addresses so they’re doing some load distribution.

    Anybody who knows mosquitto ahd has any tips please let me know.

     

     

     

    in reply to: API to pull data #7678 Report Abuse
    wz2b
    Member

    They can’t support us but I wish they would see the potential.

    Strangely, I don’t think we’re all that difficult to support … we more or less just need to be pointed in the right direction.

    in reply to: API to pull data #7676 Report Abuse
    wz2b
    Member

    All they have to do is allow their APP to use a local MQTT broker address instead of theirs during the APP setup

    How do you know it’s using MQTT, did somebody confirm that?  I suspected that was the case but was hoping for confirmation.  Checking my NAT table:

    ipv4 2 tcp 6 7395 ESTABLISHED
    src=192.168.0.126
    dst=18.189.226.239
    sport=60459
    dport=8883

    Port 8883 is the IANA registered port address for “Secure MQTT”.  So it seems likely.  I’m sure it’s doing some kind of negotiation for the TLS session.  That COULD be using certificates but it probably doesn’t expect a server cert so it seems to me you could do two things

    1. Set up your own local MQTT server
    2. Do either some DNS trickery trickery to just redirect it to yours, or some iptables trickery to do the same

    Regarding “…then you don’t need an API” I don’t agree with that.  Some people will be fine with this data going to somebody else’s service.  I would still do both.  When it comes to order of importance, having a redirectable API would be better for me personally but I suspect we’re in the minority here when it comes to customers.

     

     

     

     

     

     

    in reply to: API to pull data #7657 Report Abuse
    wz2b
    Member

    The API seems to give you an arrow now if you request more than 1 hour of 1SEC data at a time.

    in reply to: Vue Gen 2 Voltage measure. #7656 Report Abuse
    wz2b
    Member

    Thumbs up, I’d like to be able to get the voltage as well.  Less important but still useful would be frequency – California Rule 21 and IEEE 2030 define two curves (watts and vars) based on frequency.

    in reply to: Gen2 Cannot be used when internet is down #7646 Report Abuse
    wz2b
    Member

    Is there any documentation or a statement that says how much data the Vue2 is able to store (and forward later) in the event that the internet goes out?  I had an internet outage on May 15 (about five weeks ago).  I looked back at the 1 hour database and there are no gaps in the 1 HOUR data.  The 15MIN data is all gone so I can’t tell from that.  But it seems like the device itself is able to cache its data for some period of time until the internet becomes available again.  It would be great to get some understanding of how much time that is.

    in reply to: Minute level data retention limit? #7642 Report Abuse
    wz2b
    Member

    There’s no way to thumbs-up a response, but thanks for posting the data retention policy – very helpful.

    in reply to: GIDs #7641 Report Abuse
    wz2b
    Member

    I hate answering my own questions but I think this forum software locks edit after a few minutes.  I realized that the channel numbers being a string is right because to get the overall house I request channel “1,2,3”.

    Another field I questioned was HotTub which is a bool wrapped in a string, and I’m not sure why.

     

    in reply to: A suggestion for an “offline” API #7627 Report Abuse
    wz2b
    Member

    I need to edit what I wrote a little, but don’t see an obvious way to do that so I’ll just issue a correction:

    Like the Vue, the sensor itself speaks bluetooth to a device inside the house that acts as a gateway to the IP network.  So, same basic communications topology.

    I conflated the Vue2 with my Weatherflow product and said the wrong thing.  The Weather Flow is actually 2 pieces and uses BLE between them. The Vue 2 obvious is not that, it’s Wifi right out of the panel.  The rest of what I wrote still makes sense.  If the device is on 192.168.1.0/24 then broadcast UDP messages to 192.168.1.255 and anybody on that LAN that wants to listen for them can do so.  You could make it so you could turn these broadcasts on and off if needed, though I don’t see a lot of harm in just leaving them on always.

    in reply to: Allow cloudless local instance #7626 Report Abuse
    wz2b
    Member

    I wrote a separate post in the product suggestion forum but I think what I would like is to just have the emporia gateway device spit out periodic UDP updates the same as how weatherflow does it.  Look at their documentation and how simple it is.  https://weatherflow.github.io/Tempest/api/udp.html

     

Viewing 15 posts - 1 through 15 (of 18 total)