Water Leak Monitoring

Fed up with playing a perpetual game of water whack-a-mole due to pesky leaks in my home, I decided to take matters into my own hands and become the DIY superhero of plumbing mishaps. Armed with determination and a soldering iron, I concocted a water sensing circuit paired with a shutoff valve, dubbing it my "Aqua Avenger" creation. Now, when a leak dares to rear its soggy head, my trusty circuit detects it faster than a cat spotting a laser pointer, swiftly shutting off the water flow and saving the day. Who needs a plumber when you've got a bit of ingenuity and a pinch of humor?

• Valve Hardware
• Water Sensing Hardware
• The Software

Features

1. MQTT control, valve can be open/closed/locked open/locked closed by sending it MQTT messages via a broker.
2. MQTT status updates for valve position, sensors missing, button presses, sensor status, and connection issues
3. Configurable open/close durations (not all valves close in 10 seconds)
4. Easy Wifi setup, unit powers up in a wifi station mode with a randomly generated password for each device, this password is output via serial when the device is first powered on and printed on a sticker on each device.
5. Dynamic or static IP configuration, once again setup during the initial process, or can be modified from the web UI
6. Stored log events, the device stores a log of the last 20 events in memory along with their timestamps, this includes, errors, warnings and status updates for valve operations.
7. Manual and web-based valve control, buttons on the physical device, manual pin for controlling without power as well as web based and MQTT control for controlling the device remotely.
8. Ability to lock the valve even if sensors are triggering. Once a problem has been resolved the water sensors can take time to dry out. The web interface provides controls for locking a valve in an open state regardless of sensor values
9. Support for multiple valves on one network, currently an unlimited number of valves are supported with 25 water sensors per valve, each sensor module can support up to 10 sensor channels, each channel can have a maximum of 18 feet of water sensing wire.
10. Web-based firmware updater for both the valves as well as the sensors. Valves have the ability to push firmware automatically to each sensor during the registration process.
11. Supports user/password login with token-based authentication. Unfortunately still using HTTP, HTTPs is not supported at this time.
12. Sensor whitelists to provide notifications when sensors are missing for more then a configurable number of seconds
13. Single web interface that allows access to all individual sensors and their settings using token-based authentication between devices

Needed an Air Mattress Plug

I couldn't find them to buy locally so I decided to print this in TPU. The usual websites didn't have any files available so i quickly created this one. The more infill you use the more solid it becomes.

• STL File
• Raw Autodesk Fusion File.

Problems With Power Pet Dog Door

The Original Problem

In the first few days of dog ownership it was clear to me that letting the dog in and out every time she had to pee was going to be something I would need to do tens of thousands of times over her life… Some quick research lead me to power pet doors which sell a wifi dog door. https://www.hitecpet.com/petdoors.html#petdoors-wifi

This simple door has local controls on the door for open/close/in/out/etc that all work perfect. The dog wears a transmitter on her collar the transmits an ultrasonic tone that the door listens for using 2 sensors, one on the outside and one on the inside. Using these sensors the door can be configured for in-only or out-only operation.

But the coolest feature is that this door has bluetooth and wifi and can be controlled from millions of miles away using an app for IOS and Android. This is where the problems with this product lie. The Wifi control often doesn't work, and takes to long to connect when it does work. It infact takes so long that hitting the door open button in the app usually results in my dog giving up on waiting and just peeing on the floor.

I tried many things with the same horrible results, i tried the IOS app, the Android app, the web interface. All interfaces would only respond to open commands about half the time and often when it shows a connection to the door it is not actually connected. Logging out of the app and logging in again would fix the problem every 3rd attempt or so.

I have now owned the door for 1 year, the problem has been consistant over that entire 1 year span.

The Hardware

It was obvious that something was wrong with the door… With this problem being so obvious and annoying I have to assume that the problem was on my side. I take the door apart and find that the dog door houses an ESP32 WROOM chip, and some simple circuits to detect the ultrasonic tones, door switches and a simple motor controller circuit for the motor that raises the door. There is even a nice programming header for reprograming the ESP processor. So if all else fails i could write my own firmware to fix this issue if it turns out to be a problem with the vendor.

I find the IP using my routers DHCP table and get a constant ping going to see if maybe Wi-Fi is dropping, causing the door to go unresponsive. After hours of testing I find that the Wi-Fi signal is rock solid, without any dropouts.

Figuring out how this thing works

Its obvious at this point that the problem is likely in the products firmware or server configuration/code, I will now need to know how the protocols works before we can drill in a little deeper. The TCP Protocol is a good place to start, one option would be to man in the middle the door using a wireless network in my control, but that would take some time to setup and would require some hardware, so instead I try my hand at reverse engineering the web interface at https://app.hightechpet.com/web/. Using Chrome I open the inspect tools, head over to the "network" tab and start logging in.

The login process is pretty straight forward,

There are 2 pieces of information in there that we care about, our ID and the ChannelKey. These are used to connect to an MQTT server that is wrapped beind a Secure Web Sockets (WSS). The MQTT username is "Support" and the MQTT server is "iot.hightechpet.com"

Creating my own Python app

With all of this new information I was able to create a python script that uses the API to grab the ID and ChannelKey and connect to the WSS server. I could then open up the Android app and get a list of all of the commands

Download HERE

• {"config":"POWER_ON","msgId":4201,"dir":"p2d"}
• {"config":"POWER_OFF","msgId":4202,"dir":"p2d"}
• {"config":"DISABLE_TIMERS","msgId":4203,"dir":"p2d"}
• {"config":"ENABLE_TIMERS","msgId":4204,"dir":"p2d"}
• {"config":"DISABLE_INSIDE","msgId":4205,"dir":"p2d"}
• {"config":"ENABLE_INSIDE","msgId":4206,"dir":"p2d"}
• {"config":"DISABLE_OUTSIDE","msgId":4207,"dir":"p2d"}
• {"config":"ENABLE_OUTSID","msgId":4208,"dir":"p2d"}
• {"config":"GET_DOOR_STATUS","msgId":4209,"dir":"p2d"}
• {"config":"GET_HW_INFO","msgId":4210,"dir":"p2d"}
• {"config":"GET_POWER","msgId":4211,"dir":"p2d"}
• {"config":"GET_SENSORS","msgId":4211,"dir":"p2d"}
• {"config":"GET_DOOR_BATTERY","msgId":4212,"dir":"p2d"}
• {"config":"CHECK_RESET_REASON","msgId":4213,"dir":"p2d"}
• {"config":"GET_SCHEDULE_LIST","msgId":4214,"dir":"p2d"}
• {"config":"GET_SETTINGS","msgId":4214,"dir":"p2d"}
• {"config":"HAS_REMOTE_ID","msgId":4215,"dir":"p2d"}
• {"config":"HAS_REMOTE_KEY","msgId":4215,"dir":"p2d"}
• {"config":"GET_DOOR_BATTERY","msgId":4216,"dir":"p2d"}
• {"cmd":"OPEN_AND_HOLD","msgId":4217,"dir":"p2d"}
• {"cmd":"CLOSE","msgId":4217,"dir":"p2d"}
• {"cmd":"OPEN","msgId":4218,"dir":"p2d"}
• {"PING":"9082340589","dir":"p2d"}

Door Events (Door transmits these)

• {"success":"true","dir":"d2p","CMD":"OPEN"}
• {"dir":"d2p","CMD":"DOOR_STATUS","success":"true","delta":0,"door_status":"DOOR_RISING"}
• {"dir":"d2p","CMD":"DOOR_STATUS","success":"true","delta":960,"door_status":"DOOR_SLOWING"}
• {"dir":"d2p","CMD":"DOOR_STATUS","success":"true","delta":1630,"door_status":"DOOR_HOLDING"}
• {"dir":"d2p","CMD":"DOOR_STATUS","success":"true","delta":1630,"door_status":"DOOR_CLOSING"}
• {"dir":"d2p","CMD":"DOOR_STATUS","success":"true","delta":1870,"door_status":"DOOR_CLOSING_TOP_OPEN"}
• {"dir":"d2p","CMD":"DOOR_STATUS","success":"true","delta":3380,"door_status":"DOOR_CLOSING_MID_OPEN"}
• {"dir":"d2p","CMD":"DOOR_STATUS","success":"true","delta":4440,"door_status":"DOOR_CLOSED"}
• {"dir":"d2p","CMD":"DOOR_STATUS","success":"true","delta":4440,"door_status":"DOOR_IDLE"}

Protocol is pretty easy to to figure out, "dir" is "p2d" for commands sent to the door and "d2p" for commands coming from the door.

It was at this point that I learned a few more details

• The server disconnects automatically after exactly 10 minutes, doesn't matter if you send pings or not
• The Door often disappears from the server for a period of exactly 10 minutes at a time
• Events from the app sometimes appear and sometimes do not appear, this problem comes and goes in 10 minute shots
• disconnecting and reconnecting my app multiple times (<3 usually) will eventually result in responses from the door.

So the problems i was seeing with the IOS and Android app are impacting my app as well. But why are all the weird results in 10 minute durations, this has to be a clue.

Getting to the bottom of the problem.

It's at this point that I had a theory, I think there are multiple MQTT servers behind a load balancer and 1 or more of those servers are not relaying information back to the other servers. I do a quick DNS resolution on the WSS servers but this is a dead end, the servers are not using DNS based load balancing.

I open up 10 instances of my python app, each one connects to the same DNS entry, each command issued shows up in about half of the other windows, if I move to the other half of the windows and issue a command, that command gets repeated in those windows but not the other half. BINGO!!!!

So there are 2 MQTT servers or clusters that the load balancer is handing out but they do not transmit messages between them. If I open the Android app or connect to the web interface I can see that randomly they connect to one of the two servers and issue a series of commands, the app always shows as connected even when connected to an MQTT server that does not have the door connected. Pressing on any buttons in those interfaces results in no action.

So now we know the problem, how do we fix it

1. Let the company know, maybe they will fix their backend
2. Rewrite my app to constantly (every second) query one option on the door, when no response, disconnect and reconnect, issue the command again, repeat until the door responds, stay connected until the door goes unresponsive again. This will work but may leave sections of time where the door is unresponsive for 10 seconds or more and it will hammer their server.
3. Create my own WSS server, sign it with my own internal certificate and spoof the DNS for the real server on my internal network. This assumes the ESP does not validate that the cert is valid. (this is likely to work) This also has the added benefit of removing the cloud from my cloud hosted door.
4. Write my own firmware for the ESP to connect to my MQTT server and ditch the cloud service.

Why me, why are not all customers complaining about this?

This is a server problem, how are more users not having this problem.

If I ping the server and then do a reverse lookup on its IP i get the real server name of 116.251.186.35.bc.googleusercontent.com. This server could very well be specific to my region of Canada. Its also now clear that Google is hosting the infrastructure for this service via Google Cloud Provider, my bet is that its using this offering https://cloud.google.com/iot-core.

C:\Users\user>ping iot.hightechpet.com
Pinging iot.hightechpet.com [35.186.251.116] with 32 bytes of data:

C:\Users\user>ping -a 35.186.251.116
Pinging 116.251.186.35.bc.googleusercontent.com [35.186.251.116] with 32 bytes of data:

In Conclusion

I will send an email off to the manufacturer linking back to this article and see what traction I can get on that side. At least I know what's wrong now.

Auto Filling Dog Bowl

A few months back we adopted a dog from AARCS animal rescue. To lessen some of the daily routine I invested in an automatic dog food dispenser. I was looking for a similar solution to ration out water and this is what i came up with.

Parts

1. Easy clean water bowl: https://www.amazon.ca/gp/product/B00RAQBH54/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
2. 12 Volt Timer https://www.amazon.ca/gp/product/B01MRWKVM0/ref=ppx_yo_dt_b_asin_title_o00_s01?ie=UTF8&psc=1
3. Solenoid https://www.amazon.ca/gp/product/B01GL5P304/ref=ppx_yo_dt_b_asin_title_o00_s02?ie=UTF8&psc=1
4. Sharkbite Connector to T into basement water line https://www.amazon.ca/gp/product/B016M169KU/ref=ppx_yo_dt_b_asin_title_o00_s01?ie=UTF8&psc=1
5. Fittings to convert Solenoid to 1/4" https://www.amazon.ca/gp/product/B0773P7Z9Q/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
6. Fittings to convert Solenoid NPT to 1/4 OD https://www.amazon.ca/gp/product/B07XDWCDYM/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1
7. Braded line upgrade (optional, I did not do this at first) https://www.amazon.ca/gp/product/B08QPTZWBW/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1
8. 12 Volt power supply https://www.amazon.ca/BENSN-Compatible-Universal-Household-Electronics/dp/B082XRJ4LN/ref=sxin_9_ac_d_rm?ac_md=1-1-MTJ2IHBvd2VyIHN1cHBseQ%3D%3D-ac_d_rm&cv_ct_cx=12+volt+power+supply&dchild=1&keywords=12+volt+power+supply&pd_rd_i=B082XRJ4LN&pd_rd_r=a337a1a3-5456-48af-94b4-f6e8866fb0a3&pd_rd_w=Oh4U0&pd_rd_wg=ckefC&pf_rd_p=8642c3cb-9fcf-4c84-93d6-c72c3fa128ad&pf_rd_r=1WD2GHA7A46RS923QXVB&psc=1&qid=1614293201&sr=1-2-12d4272d-8adb-4121-8624-135149aa9081

These parts together will create a water bowl that you can schedule fill times on. Currently I have programed the bowl to fill at 7AM and then top up again at 9Am, 11Am, 1Pm, 3Pm, 5Pm. Each time the water fills for a period of 1 minute and then stops. The float inside the dish will stop the dish from overfilling.

This is what the timer and solenoid look like in the basement, I mounted everything to a metal plate and secured it to the wall beside my furnace.

If your interested in recreating this, here's the basic wiring diagram that also adds a 3 position override switch that allows the system to be bypassed on, bypassed off, or set to auto

My Atari 7800 Needs an RGB mod.

Over the last few weeks of Covid isolation i have been working to RGB mod each and every console i own that came out before the invention of component or HDMI. Every console has a published solution or kit that i was able to purchase/build and install with the exception of one console. The Atari 7800.

Most consoles have a native RGB signal on the board that just needs some simple tweaks to bring it in compliance. Those that do not require more work, solutions vary from adapting existing signals, assuming they are of sufficient quality, up to the much more difficult complete emulation of the graphics chip.

The Atari 7800 problem goes one step further. There is no signal on the motherboard that holds sufficient quality to adapt. On top of that the 7800 has two graphics processors, the Maria chip, for 7800 games and a 2600 chip called the TIA to run the older 2600 games.

Now to finding a solution.

There is already a solution for RGB modding the 2800 by desoldering the TIA chip on the 2800 and adding a board that intercepts the signals on route to the the TIA chip http://etim.net.au/2600rgb/ , it uses at 64 GIPO processor (the cy8c3244axi) to read the address lines in real time and recreate the video output using a tr9c1719-66dca video DAC with 3 channels (red, green, blue). i own one of these boards and it works great.

The solution for the 7800 requires solving 2 problems, the first is to render the data destined for the Maria chip (for 7800 games) and to render data that was destined for the TIA chip (for 2600 games). My focus here is to make this work for 7800 games first, the 2600 problem already has s solution, once the 7800 works 2600 support can be added in later

Option 1, drop in replacement for Maria. Someone has already done the leg work to reproduce the chip https://atariage.com/forums/topic/154745-maria-chip-has-been-resythensized/page/5/#comments this could be adapted to add RGB functionality. But silicon is expensive.

Option 2, unsolder the Maria chip, install a header and use a small board to tap into the address lines, data lines and chip enable lines. The address bus under the maria chip is the same used by the TIA chip so these same pins could read data destined for the 2600, we just need to monitor a different address space. We may need an additional wire to the TIA enable pin however i think we can assume if the Maria enable pin is low the TIA enable will be high (easy to test)

So lets start down the path of option 2 and see if we run into any problems. First we will need the pinout of the Maria chip

There are 4 versions of this chip

C024674 7800 NTSC older
C025349 7800 NTSC newer
C025314
C025718 7800 PAL

I believe all 4 have the same pinout. It looks like this pinout will give us all the signals we need plus a few we dont. The plan will be to use this chip still, we are just going to watch signals move between the bus and the chip and recreate a video output, existing composite/rf/svideo mods will not be impacted. The address bus also has the TIA chip as well so we will see traffic destined for the 2600 chip as well, Maria will be ignoring it but we dont have to.

Now that we know the basic hardware layout we need to know the address space the maria chip works with and what each address in that space would normally do. I was able to find this site that lays out the addresses of each chip https://atarihq.com/danb/files/78map.txt as well as the addresses used inside the Maria chip.

Then i found this fantastic document http://www.atari7800.org/manuals/7800_Maria_Specs.pdf that outlines the behavior of the Maria chip, descriptions of the physical chip, etc.

I also found this great diagram that shows the timing cycles that the Atari uses. Turns out the resolution output of the Atari is not set in stone, Program code has to run in the blanking period however if your game did not need as much time for processing its possible to shorten the blanking period and increase the horizontal or vertical resolution.

The next step for this project is to:

1. Remove the Maria chip from my console
2. Add a socket
3. Have a board made that breaks out all maria pins to an IDE cable header
4. Make another board that brings the IDE cable header into a breadboard.
5. Decide on a suitable processor that is fast enough to build and put one frame worth of data into a tr9c1719-66dc before the next frame needs to be built. I think i will only need one interrupt triggering off the clock signal. I bet i could use the same processor currently used by the Atari 2600 RGB mod.
6. Write code to interpret the data and output 7800 frames to my computer over a debugging cable. (doesn't have to be real time at first)
7. Optimize that code to run fast enough to not lose any frames
8. Write code to output those frames to the tr9c1719-66dc instead of my computer
9. Breadboard up the tr9c1719-66dc along without outputs to scart using a BH7236AF, test
10. Draw up the final circuit in easyeda, get some boards made
11. If everything works shift focus to write software that attempts to render 2600 video using the same address pins and maria enable pin.

Extra considerations

1. The palette will need to be recreated (color reproduction on Maria would be approximate, colors are set into the palette addresses on the Maria chip, we get to interpret those colors how we see fit. The NesRGB handles this buy having several options selected with a switch, we could do the same. People always have opinions about this kind of thing (we could get the color RGB values from framemeister configs meant for the Atari 2600)
2. i could cheat and buy a https://etim.net.au/shop/shop.php?crn=210&rn=552&action=show_detail 2600RGB, simply make an adapter board that moved the address pins from the TIA layout to the Maria layout, I would need to add a few additional address lines because the TIA has a smaller address space, maybe i could borrow them from other pins or add a few bodge wires. I could then erase the data on the 2600RGB and replace it with my 7800 firmware. This could speed up prototyping
3. I should look into how controller input is read, maybe that comes across the address bus, if i could capture input i could use controller combinations to set pallet information (up up down down left....). Or maybe i could read the consoles physical switches. **UPDATE** Controllers are read directly into the 6532 RIOT chip, this data does go across the bus, to the CPU, i can sniff this data as goes across the bus.
4. While a simple board gets us 2600 and 7800 video signals, we still need additional wires to get audio (its not part of the Maria chip). Audio comes from the TIA chip as well as the cartridge slot. I need to grab this signal after they are mixed together, maybe at the RF modulator, voltage levels will need to be checked. This should also run through a small non polarized capacitor before being sent out the scart cable.

Sources

1. http://www.atari7800.org/manuals/Devcard.htm
2. http://www.atari7800.org/manuals/7800_Maria_Specs.pdf
3. https://atarihq.com/danb/files/78map.txt
4. https://atarihq.com/danb/a7800.shtml
5. https://atariage.com/forums/topic/244830-maria-diagram/
6. https://atariage.com/forums/topic/154745-maria-chip-has-been-resythensized/#comments
7. http://www.qotile.net/minidig/docs/stella.pdf
8. https://atariage.com/7800/archives/schematics_ntsc/

Dead RV Camera

More RV problems. The passenger side camera stopped working.

This is a photo of the back of the monitor, I tried hooking up the passenger side camera to the driver side monitor input. That showed me that the camera was in fact broken.

I removed the two screws that hold the cover on, Using this photo i was able to find an identical replacement on Ebay for $80. The new camera bolted back into the same bracket without any issues. I then filled the hole and screws with silicone.

Always a win when you can fix something on the RV for under $100

RV Problems

When heading home from camping last year the engine in the RV started to overheat and the check engine light popped on. I pulled over to let it cool down, no coolant was leaking, everything seemed fine. Once cooled down the RV was fine, I got up to 100Kph and it didn't overheat again. When I pulled it out after it was in winter storage I found that it would stay cool when moving 100Kph but not for stop and go traffic.

I started with the obvious, the thermostat. It can be accessed through the floor between the driver and passenger seats. Unfortunately this did nothing.

Next, I replaced the cap to the coolant reservoir.... turns out I am not that lucky.

next up was the temp sensor. The RV never boiled over or steamed... so i thought that maybe it was just lying about overheating.... replaced the sensor, no change.

Next up was the mechanical cooling fan, for this I needed to buy some new tools, even with these tools the fan is really hard to get to. Anyway, no luck, didn't fix the problem.

So the only things left are the radiator itself or the water pump. the water pump isnt leaking but if I am going to go to all the trouble of removing the radiator I may as well replace the water pump while I am there.

I had to remove a bunch of wire clips from the fan shroud. After that, the two bolts from the top of the shroud were removed. The shroud itself is still locked in by the fan clutch.

Now from the front of the RV I dug down to the bolts that hold the top of the radiator down The Airbox had to be removed and some rubber shrouding.

now I could disconnect the trans lines from the radiator and the upper and lower rad hoses. Now it's possible to remove the mechanical fan so it sits inside the fan shroud. Then remove the shroud with the fan inside it. Then the radiator can slide up an inch or two releasing the bottom pins. Then the base can be slid back toward the engine and down to the ground. The RV had to be jacked up 2 feet to make room to fit the radiator out the bottom.

Now I could get to the front of the engine by putting my body where the radiator used to be. I removed the belt and removed the pully from the front of the water pump with a puller. This gives access to the bolts that remove the water pump.

Then the new pump went in using a new O-Ring. Belt was reinstalled, new radiator installed, fan shroud reinstalled with fan loose inside. Fan then bolted back up and all of the lines were reconnected.

Camping Projector Mount

A few years ago I purchased an inflatable projection screen that is made out the same material Zodiac boats are made from. We have used this a number of times while camping but the projector is always hard to setup. It requires pulling over a picnic table which obscures the view or piling up logs to try to get the projector in the proper place. The company i work for makes short throw projectors so an experiment needed to take place.

I took our factory projector plate and welded a bottom plate to it. I then tapped the plate with 1/4x20 hole to receive the tripod mount.

I would say that this was both a success and a failure. The tripod mount was a win. However short throw projectors should not be used for outdoor screens. The screen moves in the wind and small changes to the screen make large changes in the picture size and shape. So when the wind gusts, the picture moves drastically. Once i got home i created a new plate for my NEC long throw projector. This will work better moving forward.