-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General guidance on how to "get started" with the stack #4
Comments
This project is 98% the docker compose stack that yes does DNS poisoning of the first API call the hub makes to download the official credentials from surepet then rewrite them to have an easier MQTT topic name then point to a MQTT instance that is also part of the compose that listens on 8883 and relays messages from that MQTT instance to your main Home Assistant instance where the last component pethub listens to the messages that the hub creates on your home assistant MQTT instance from the hub and home assistant and translates between the two. I thought the readme in the docker folder but will update the main readme as well to reflect that. There is also zigsniff which is a stack to sniff the Zigbee traffic and decrypt it and the wemos hub but that was before I figured out how to find the certificate password and once I did that it was not worth putting any effort in as I could monitor all messages in both directions using PolarProxy. Does that help and now I know the areas in my readme I need to update as I know documentation needs some work. |
If you wanted to work on your own hub solution then Marks app works on a Pi or similar using the MRF radio as does my wemos code that works with the same radio but on a wemos/arduino rather than a Pi but I didn't finish that as I got the hub working and the messages the devices send is the same anyway so even if we did build a new hub you would still need pethubpacket to translate the messages and I didn't fully get to the bottom of the crc for the Zigbee/802.15.4 frame. Technically it's a 802.15.4 frame that has the data frame being XORed with a static key, and the beacon frames aren't encrypted. |
Hey @plambrechtsen,
Thanks for the super fast response!
I think your answer pretty much covers what I needed to know 👍
Indeed, all what was kinda needed is to put some more emphasis on the first
section (describing what you put in `docker/`), while describing that the
rest is dev tooling.
I will probably try the MITM approach only after trying using the antennas
directly: the CRC part seems to have been figured out too. Having a piece
of equipment that cannot ever receive firmware updates (because locked out
of WAN via DNS poisoning) seems a but scary long-term 😬
…On Fri, May 7, 2021, 20:17 Peter Lambrechtsen ***@***.***> wrote:
If you wanted to work on your own hub solution then Marks app works on a
Pi or similar using the MRF radio as does my wemos code that works with the
same radio but on a wemos/arduino rather than a Pi but I didn't finish that
as I got the hub working and the messages the devices send is the same
anyway so even if we did build a new hub you would still need pethubpacket
to translate the messages and I didn't fully get to the bottom of the crc
for the Zigbee/802.15.4 frame. Technically it's a 802.15.4 frame that has
the data frame being XORed with a static key, and the beacon frames aren't
encrypted.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABFVED2WDDL37TOQJPOTY3TMQVCLANCNFSM44KK6GVA>
.
|
If you have a hub and setup the docker stack correctly it also downloads the current firmware for your hub by default so you can reapply it as many times as you want. |
Hopping in here as this counts as "getting started". I've just bought a cat flap connect and hub and plan to use it with this for a no-cloud solution. Thanks for your work on this @plambrechtsen ! It sounds like I need to initially set up an account on the cloud surepet API before proceeding with the |
"Technically" you don't need to connect to the cloud it is just it makes life much much easier to get yourself going if you use their cloud service. Depending on the hardware revision of the hub (ie a H010-xx or one of the older ones H008 or lower) then if you connect it first up to the docker stack you get the long_password which is the password for the SSL Certificate. And if it is a H008 or older then it needs to be firmware updated first, which is just easier to do using the cloud. The devices first need to be adopted to the hub, which you can use the command line tool: Otherwise if you sign up to the cloud service, ideally using a desktop browser to https://surepetcare.io since then you can see all the APIs being called then the If it is a older Hub (ie H001-H009) then I would be VERY interested to see what the initial boot is to the docker stack. |
I also made major changes to the main readme @Ocramius so hopefully that helps you too. |
I think everything has been covered, so closing this. |
Hey there! First of all, kudos for trying to emulate the whole Pet Hub.
Background
I'm trying to understand a couple details about this repository, mostly because the
README.md
seems to include multiple diverging approaches to how to get these devices to publish to MQTT (I understand that this is the result of a lot of try-and-fail).I'm currently sitting here like a complete moron with a ConbeeII in my hands, and realizing that it's pretty much useless :D
Questions
Thank you in advance for any guidance!
Breadcrumbs
Meanwhile, for others that are as lost as I am about avoiding the SurePetCare Hub, here are some references about stuff that brought me here:
The text was updated successfully, but these errors were encountered: