Then this solution isn’t for you! If your use case involves your car being within WiFi range of your home but you’re not going to be going in and out of the garage, then it isn’t a good fit. That includes people who tend to drive past their house regularly, or sometimes park outside, or whatever. The project is very simple - if your car can talk to wifi, it’s going to open the door. When it can’t, the door will close. Users need to be sure that they are OK with these two simple rules.
In that case this project will increase safety. It acts as a second check for you - even if you (or somebody other than you) starts your car without checking that the door is open, it will go ahead and do that for you. Security measures often work best when applied in depth.
Garage door openers have been around for decades and have pretty robust safety systems (beam sensors, auto-reverse on obstructions, etc) built-in, particularly if purchased after 1991. However, there’s no reason you couldn’t work your existing additional measures into the automation here so that all those things still happen before you open or close a door.
Agreed. Except some of the solutions I’ve seen here contravene national electrical codes, long-established safety procedures, or assume optimal conditions and have no mitigation for failure modes. Sometimes people understand the risks and accept them (“to each his own”) and other times they’re simply unaware of the potential risks (“Oh, I didn’t think of that”). My comment is addressed to the latter.
I can’t disagree with your logic; in this scenario it would definitely be safer to have the garage door open automatically to compensate for the highly inadvisable practice of starting a car in a small, enclosed space.
Except you’re promoting it as a safety feature when, in fact, the intent of this system is to control the garage door. This system requires you start the car inside the garage in order to open the door (normally an inadvisable practice). So, not a bug but a feature?
No disagreement from me. It fits a very specific use-case and that’s all I wished to point out. Many people in my neighborhood park either inside or outside, so this system wouldn’t be a good fit neither for me or my neighbors (unless suitably adapted).
Yes, they do, and they also have documentation warning users to ensure the area is free of obstructions prior to closure. They expect the door’s operation to be attended, not unattended, even with the inclusion of safety systems.
The safety systems were added (around the 70’s, if I’m not mistaken) because people didn’t follow this advice (resulting in injuries and fatalities). The same documentation requires you to adjust the closing force and test it periodically. I imagine few people are even aware of this task let alone having performed it.
It’s all matter of how much risk one is willing to tolerate. In my case, I prefer the added protection of an audible warning announcing the door’s impending closure. Others may be comfortable with never having checked the closing force and have it close without warning. Indeed, to each his own.
I think the biggest challenge I had was the assumption that you could automatically close the garage door after you got home. In my case, when I am unloading the car, the hatch would be up and get hit by the door as it tried to close. I ended up using a second D1 Mini attached to a ultrasonic sensor to determine if the car was in the garage to prevent closure.
They can be dangerous (see following report for 7-year period in the 80’s)
It’s the heaviest moving component of a home that poses a crushing/asphyxiation hazard (excluding a vehicle, of course). Fortunately it is mostly rendered benign due to safety mechanisms and when operated within its ‘design envelope’.
When you make a garage door close for any reason other than by your manual and deliberate command, you are operating it outside its intended ‘design envelope’. You are effectively expanding the scope of operation and, for safety reasons, ought to consider the potential new failure modes that may compromise the device’s safety and cause harm to persons or property. That’s the responsible thing to do (and for a practicing engineer, a requirement).
@dap35 has identified one failure mode where the door would, dutifully but undesirably, close and damage the vehicle’s open hatch. Superior presence detection (ultrasonic sensor) was required to override the auto-closure system and render the situation safe (again). This is the sort of analysis, and mitigation, that is needed whenever one either modifies a device or uses it in a manner that differs from its original design. That sums up what I’m encouraging automation hobbyists to do.
That study resulted in new regulations regarding automatic garage door openers which went into force in 1991 (which I why I mentioned that earlier).
Again, it’s up to the user how they want to handle this, but dredging up 30+ year old studies to scare people away from using garage doors is stretching things a bit.
The inclusion of the article was to drive home the point that the door has the potential to cause damage, or injury, even death. The advent of obstructions and resistance sensors (and auto-reverse) was a response to proven dangers. However, the assumption is that the resistance sensor is properly calibrated and periodically tested (as per the manufacturer’s own recommendation). It’s my position that this maintenance is rarely done and so one ought to err on the side of caution when automating its operation (i.e. automatic, unattended closures).
I believe if you review what I’ve written, there is nothing there to support this claim. My intent is to sensitize home automation hobbyists to the need to understand the ramifications of altering a device’s ‘design envelope’. One may unwittingly create more failure modes that, if unmitigated, present a greater risk of property damage or personal injury. That’s the long and short of it.
Full log:
[INFO] Setup mosquitto configuration [WARN] SSL not enabled - No valid certs found! [INFO] No local user available [INFO] Initialize Hass.io Add-on services [INFO] Initialize Home Assistant discovery [INFO] Start Mosquitto daemon 1547672346: mosquitto version 1.4.15 (build date 2018-03-04 15:14:46+0000) starting 1547672346: Config loaded from /etc/mosquitto.conf. 1547672346: *** auth-plug: startup 1547672346: ** Configured order: http 1547672346: Opening ipv4 listen socket on port 1883. 1547672346: Opening ipv6 listen socket on port 1883. 1547672346: Opening websockets listen socket on port 1884. 1547672346: Warning: Mosquitto should not be run as root/administrator. 1547672346: New connection from 192.168.1.72 on port 1883. [INFO] found xiripi on Home Assistant 1547672347: New client connected from 192.168.1.72 as lens_zOCwNHCiOr3knP2ZynnLbHIDfdL (c1, k120, u’xiripi’). 1547672347: New connection from 192.168.1.97 on port 1883. 1547672348: Socket error on client <unknown>, disconnecting. 1547672348: New connection from 192.168.1.97 on port 1883. [INFO] found xiripi on Home Assistant 1547672348: New client connected from 192.168.1.97 as 5a2983f5-f995-4da9-bc22-8062a33c2f9d (c1, k60, u’xiripi’). 1547672348: New connection from 192.168.1.128 on port 1883. [INFO] found xiripi on Home Assistant 1547672348: New client connected from 192.168.1.128 as garagem (c1, k15, u’xiripi’)
Looking here for the actual MQTT traffic, not the service log. If you have mosquitto client installed, you might be able to do that with the following command:
mosquitto_sub -h 192.168.1.97 -u user -P pass -t "#"
Notice that “u” is lowercase and “P” is upper case.
The fact that other messages are being sent, but not this one, strongly suggests that you didn’t successfully change the PubSubClient max message size. That string is 168 characters long which will trip over the default limit of 128. Follow the instruction here carefully.
It’s possible you may be modifying the wrong file, as Arduino can drop multiple copies of that library into different folders depending on how your system is setup. Follow the instructions to find the correct library folder. I have reason to believe this is your problem - it’s sending packets that are under 128, but not sending packets that are larger.
You can further confirm by watching the serial monitor vs the MQTT traffic. At startup you should have a serial message MQTT binary_sensor config that should happen at the same time as a JSON packet like the one I posted above appears. If you get the serial output, but no packet, and other packets are working… It’s almost certainly the library.
