I have not. I only have the cat door, which I don’t think works yet. Correct?
It’s twofold. You could either use the official connect hub and connect it up to my docker compose backend after altering the local DNS in your network… or build a wemos D1 with the MRF24 radio on top, or use Marks code with a Pi instead to achieve a similar outcome.
My focus has been documenting the protocol and messages in both directions and setting commands and now it is hooking up my code to send normalised MQTT messages into home assistant, then having messages sent the other way to do things like set curfews/lock the doors and set target weight on the feeder.
I have decoded the protocol for the most part, just need to write the code to support it.
Not yet. But if you collected the incoming MQTT messages I think I should be able to alter the code from there. As I now know what I am looking for.
Getting the local docker stack setup is a bit involved so I would suggest you get your head around it and see what logs get created.
Start here and see what gets put in the output folder when the cat comes in and out.
Then you can swing the dns back to the main cloud service after capturing those messages
For this testing, will I need another zigbee controller? My assumption is that I can’t use the one already associated with my HA installation.
You’ll be able to use the connect hub to connect to a local web server and MQTT instance which gets spun up with the above docker compose. Then the separate docker instance listens to the new topic and sends messages to your normal MQTT instance.
The main thing is you first need to have the credentials web server listening on 443 and then the MQTT over TLS on 8883 listening to take the requests from the hub.
It is all over TLS but the hub accepts any certificate you give it.
Sorry for my bad english. So if o don’t buy the official hub i will be not able to let the door communicate with home Assistant?
Hi
I have the cat door.
I used your docker stack tonight, and I have been able to capture the startup sequence of the hub, and the messages generated by 2 of my cats going through the door in each direction.
What do you need? Is the mqtt.*.log file from the output/msgs folder sufficient?
K.
Potentially you can build your own hub using the Wemos MRF hardware: https://github.com/plambrechtsen/pethublocal/tree/main/WemosPetHub and https://github.com/plambrechtsen/pethublocal/tree/main/WemosMRFShield for the hardware to provide the same capability as the hub. But the code in WemosPetHub still needs work to be completely functional so I personally just going out and buying a hub… and if you do… we should chat first before you power it on and connect it up to the internet.
Yes… the boot sequence of the hub and catfap, plus animals coming and going are exactly what I am looking for… send me an email offline with the timings of when things happened with the logs and I should be able to figure out what is going on… https://github.com/plambrechtsen/pethublocal/blob/3b28208aa9f483892adc95bb06c32e4bfbf226e1/PetHub/pethubpacket.py
Update for the cat flap… just not 100% sure of the direction thanks to @kimagure so committed an updated pethubpacket.py and need to confirm the bytes at offset 16/17 and which direction the pet actually went in.
Do you have everything you need for the cat door?
Not 100%, I have a few things left. One is the timestamp that is sent for the 126/127 feeder and I am working on figuring out how it is calculated. It seems to be a timestamp at offset 04-08. I am getting timestamps like this.
Feb 20 23:04:21 - 6030dea6 0450 126 12 16 00 ea 03 7b a0 a8 54
And the timestamp is: 7b a0 a8 54
It isn’t a normal UTC Unix timestamp which is the first value 6030dea6, and it seems to be the last two bytes are the days divided by two, and the first two are seconds.
This is the python I am working on but it still isn’t right.
from datetime import datetime, timedelta, timezone
def tohex(ba):
return ''.join(format(x, '02x') for x in ba)
def b2is(b2ivalue):
return str(int.from_bytes(b2ivalue, byteorder='little', signed=False))
val="7ba0a854"
hexval=bytearray.fromhex(val)
intdate = int(b2is(hexval[2:4]))
intdatemod = intdate % 2
intdatediv = round(intdate/2)
inttime = int(b2is(hexval[0:2]))
if intdatemod == 1:
inttime += 65535
date_and_time = datetime(1991, 6, 17, 1, 0, 0).astimezone(timezone.utc)
newdate = timedelta(days=intdatediv,seconds=inttime)
current=date_and_time+newdate
print(current.replace(tzinfo=timezone.utc).astimezone(tz=None))
Haven’t figured that one out yet…
This is incredible work. WOW
Should have known it would be a bit offset:
def bit2int(number,start,bitlen,fill):
return str(int(bin(number)[2:][start : start+bitlen],2)).zfill(fill)
def feedertimestamptostring(number):
return '{0}-{1}-{2} {3}:{4}:{5}'.format(bit2int(number,0,5,2),bit2int(number,5,4,2),bit2int(number,9,5,2),bit2int(number,14,5,2),bit2int(number,19,6,2),bit2int(number,25,6,2))
val="7b a0 a8 54"
feederts = int.from_bytes(bytearray.fromhex(val),byteorder='little')
print("Timestamp as hex "+val)
print("Timestamp as integer",feederts)
print("Timestamp as string " + feedertimestamptostring(feederts))
Gives me
Timestamp as hex 7b a0 a8 54
Timestamp as integer 1420337275
Timestamp as string 21-02-20 10:01:59
Since it is Easter weekend I’ve spent some time today on it. Updated the database to include the animal type so it shows as the MDI type. And now publishing the pet door status. Going to work on the feeder tomorrow and should have locks done for the pet door shortly too.
Still haven’t got enough detail on the cat flap for curfew and checking animal has come in or out via the cat flap.
I think everything I need has arrived now. The big work for me will be getting the soldering right. Then I can flash and start testing my pet hub.
What do you need for the catflap? I can do additional data capture during the weekend.
I’ll make sure to double check the direction of the cat (going out/coming in) to confirm your assumptions.
K.
The things I am looking for is
- cat entering and exiting
And if you have a CC2531 or the above Wemos + MRF24J40 or similar zigbee adapter to sniff traffic the following events while connected back to the cloud service would be great.
- enable / disable curfew
- set curfew to 11:14 - 13:48
- set curfew to time before current time so as soon as it is set the door should lock.
Since the above you need to set the values via the cloud service and then capture it using the CC2531 or some other zigbee sniffing hardware.
The soldering is pretty easy, I do recommend soldering the underside first, solder the RESET on the left to the D4 pin not the main reset pin, and I setup CS on D0 rather than D8.
Then if you solder the short socket pins first onto the wemos then soldering the pins and the MRF24J40 onto the top is a piece of cake.
But the wemos code still needs a bit of work, whereas using the standard Surepet Hub with the docker compose stack and changing the DNS entry for the most part fully works for me. Just adding further capabilities into it now.