- This topic has 11 replies, 4 voices, and was last updated 5 years, 9 months ago by
.
-
Posts
-
@lawrence_jeff touch on it here … https://opengarage.io/forums/topic/fork-with-mqtt-close-if-left-open-at-night-misc-other-changes/page/4/#post-724
I wanted to bring all the discussion into one place here. Look at which pins and how. The goal is to add the second sensor, make it backward compatible with older hardware and make it a simple hack if someone with older hardware would like to add it.
- All this is just thinking out loud, so please comment.
Maybe do it in two phases.
Phase 1. As Jeff suggested, add it to the API. I have looked at what is involved to add it to Home-Assistant (HASS). Looks like a simple change once the json response is updated.
Phase 2. Tackle the UI.So, lets talk pins. Right now I am working with a hello world testing different ideas. Trying to save pins on the ESP8266, I tied sharing the trigger, and got some flaky results. Not sure if the issue is the closeness of the sensors and sound transmitter interfering or not enough current on the pin to drive two triggers. Jeff suggested looking at 3 wire configuration. I have not got that to work yet, I keep getting 0 distance. Once I get some time and check if I have a bug, I will post some code here. After thinking about it, I may go back and try to get the common trigger working, if the issue is not current draw, then that would make the “adding second sensor hack to existing OG hardware” easier.
First discussion, how to make the pin definitions more configurable? Jeff, I think you had some thoughts on this. Would you like to share? I might understand where you were going in our conversation, let me test it here ….
Lets Create hardware categories. I think only sensors fall into this category. For example the relay and buzzer will always be the same. If true then where sensors are read there could be different flow control depending on which sensor option package is chosen. To keep the sensor update simple, at the start initialize all of them to a used value. Then at the program runs only the senors used will be updated. The API will return all sensors, with a field saying which sensor package is being used.
So far here are the Sensors options I see (help me refine this list, and give them names)1. Original OG A. Door Open B. Distance C. Vehicle D. Temperature E. Humidity 2. Jeff's Micro switch A. Door Open B. distance ? C. Vehicle ? D. Temperature E. Humidity 3. Original OG with second sensor hack A. Door Open B. Distance C. Vehicle D. Distance2 E. Vehicle2 F. Temperature G. HumidityAlso we need to come up with a short name for each sensor category. For example original OG might be OOG. Then the pin names would be OOG_PIN_ECHO, OOG_PIN_TRIG. Or would it be better PIN_OOG_ECHO?
I would get 1 GPIO Distance sensing work as an easy first step that makes all the code 1:1 as far as open GPIO to devices – I haven’t had any issues in my setup and it shouldn’t be a current issue since the code won’t power both sensors at the same time.
So starting with a single Ultrasonic sensor – you connect power and GND and the GPIO to both trig and echo.
When you run this you get back 0 for a distance?@lawrence_jeff Thanks. Bottom line on the sonic sensors. After a bit of testing, 2 can share the same trigger. I think even though the transmitters are firing at the same time, if they are close they act as one transmitter. I found angling a hard surface played with the readings more than how close they were. The thing I could not get to work is wiring a 4 pin HC-SR04 like a 3 pin sharing the trigger and echo such as http://andrewjkramer.net/ultrasonic-sensors/ In hindsight not sure how that would work, would not the echo single trigger the “trigger”?
Anyway, I am now trying to dig into how you are using JP2 (3,4,6) / Options (23,24). I also bought a mag switch. I wonder about using it for door open and the two distance for cars preference. That way the home automations can make better decisions.
Some of my parts are starting to roll in now, still missing some. Thats ok, it will take my some time to digest the code.Just to clarify, having two share the same trigger is not what I am recommending nor what I have in the code, that will be inherently problematic in our application. My code uses the 3 wire mode as in the URL you sited, this ensures that only one sensor is active at a time and prevents one from confusing the other.
How this mode works – is that it sets the pin to output mode, sends the pulse to trigger a measurement (ignored by the echo pin) and then quickly shifts the pin to an input so it can read the reply signal (ignored by the trigger pin). I would get this working in your setup if you plan on using more than one sensor – Not sure what issue you are having – i would start with using one sensor and figure out why it isn’t working. Are you powering the sensor with 5v or 3.3?
I have not figured this sites markdown and style conventions yet, so I just guessing.
- Are you powering the sensor with 5v or 3.3?
5V
- My code uses the 3 wire mode as in the URL you sited
Ok, let me make another run at it. My code is on my mac at home. Just to be clear, I am using the read distance and read distance once functions from the OG class. I am passing the same pin number for the Trigger and Echo. Let me do some work and I will post the code and pictures of my breadboard if I can’t get it to work.
BTW, I sent you a couple of pull requests that fixes ap_home and compiled the html2esp code for macbook.
AND
I hope to have some time to spend on it tonight. Today is an exciting day. Leaving work early to get my house connected to fiber. Maybe hard to believe there are houses in America without internet. All I had was a cell hotspot. The cable, phone, and such said our town did not have the density. So our neighborhood is part of a pilot that the city is bringing the infrastructure and will contract out the supply. Just like they do with gas and trash. So my bill will have a line item for water, sewer, gas, trash, and internet.Sorry took so long, setting up the home network. Never had access to a public IP before, I was behind 2 or 3 different NAT with the hotspot.
Anyway, tried the 3 wire again. Not sure what I am missing, maybe a second set of eyes.So I cut the read_distance and read_distance_once straight from the OG. Then I call the read_distance from the loop. One sensor.
If I wired it for 4 wires I pass the correct PIN_TRIG/PIN_ECHO. If I wired it for 3 wires then I pass the same pin (PIN_TRIG/PIN_TRIG).
You can see where I can comment/uncomment to switch back and forth. Three wire gives me all zeros. It’s almost like the pin mode is not switching. I am linking to some pictures, but I don’t know if they are good enough to help.
Do you have something you could try and see if you get same results? Not sure if it matters, I am using a NodeMCU V3./** GPIO pins */ #define PIN_RELAY 15 //D8 #define PIN_BUTTON 0 #define PIN_TRIG 12 //D6 #define PIN_ECHO 14 //D5 #define PIN_LED 2 #define PIN_RESET 16 #define PIN_BUZZER 13 //D7 #define PIN_JP2_4 5 //Jumper 2 ping 4 which is GPIO 5 d1 #define PIN_JP2_3 4 //Jumper 2 ping 3 which is GPIO 4 d2 (Reserved for switch primary door) #define PIN_JP2_6 0 //A0 #define pingPin PIN_TRIG void setup() { // put your setup code here, to run once: Serial.begin(115200); } void loop() { // put your main code here, to run repeatedly: Serial.print("Distance 1 "); //uint dist = read_distance(PIN_TRIG,PIN_ECHO); //Works uint dist = read_distance(PIN_TRIG,PIN_TRIG); //Returns 0 Serial.print(dist); Serial.println(""); delay(1000); } long read_distance_once(int TRIG, int ECHO) { //TODO handle max value as handled error in the UI - check long distance for car detection pinMode(TRIG,OUTPUT); digitalWrite(TRIG, LOW); delayMicroseconds(2); digitalWrite(TRIG, HIGH); delayMicroseconds(10); digitalWrite(TRIG, LOW); pinMode(ECHO,INPUT); // wait till echo pin's rising edge unsigned long quit_time=micros()+26233L; while((digitalRead(ECHO)==LOW)&& (micros()<quit_time)); {//Do nothing }; unsigned long start_time = micros(); quit_time=start_time+26233L; //wait till echo pin's falling edge while((digitalRead(ECHO)==HIGH) && (micros()<quit_time)); ulong lapse = micros() - start_time; if (lapse>26233L) lapse = 26233L; //DEBUG_PRINTLN(F("Distance issue, setting to low value")); //DEBUG_PRINT(lapse); Serial.print(" lapse "); Serial.print(lapse); Serial.print(" "); return lapse; } uint read_distance(int TRIG, int ECHO) { byte i; unsigned long _time = 0; // do three readings in a roll to reduce noise byte K = 3; for(i=0;i<K;i++) { _time += read_distance_once(TRIG, ECHO); delay(50); } _time /= K; //echo_time = _time; return (uint)(_time*0.01716f); // 34320 cm / 2 / 10^6 s }
Ok I found a sensor that did the same thing as yours using this code – Adding debugging into the code it was failing at this part
while((digitalRead(ECHO)==LOW)&& (micros()<quit_time));
{//Do nothing
};and exiting out of the loop due to micros() getting larger than the quit_time..meaning it never detects the beginning of the pulse it needs to measure to determine distance. That exit condition was there mostly to stop the ESP from doing a watchdog reset and the code really should quit the function at that point since something is wrong and the measurement after will not be correct.
Looking around a bit I found an article that recommended connecting echo to Trig via a 2.2k resistor instead of directly. Adding that in fixed it for me. It seems some configs are just more sensitive than others.
So I have VCC -> 5v on the nodemcu (VIN)
GND -> GND
D6 –> TRIGAnd then TRIG -> 2.2k resistor ->ECHO
Thanks for sanity check. 🙂
My assortment of resistors are at work. All I have today are a few led current limiting and putting them in series was not enough. I will test it, which I am sure it will work, when I can get access to them, maybe Monday.
My first thought was maybe the pin mode could not switch fast enough. I tested some delays, still did not work.
Switching thoughts for a second. I been digging through your code trying to get my bearings. Also I read the post on mqtt.
I like the direction with the drop down box, switching function of the input pin.
Looking at MCP23017 16-Bit-I-O-Expander-with-I2CI have two different train of thoughts. 1 is like above select a combinations of sensors or level of configurations.
Level of Configuration
What about 2 Categories of drop down boxes.
1. Hardware OG/NodeMCU without expander,NodeMCU with expander
2. List of supported Sensors and what pin they are on.
The pseudo logic would be for example Hardware OG, All the second group will be hidden and would expect the OG hardware. The NodeMCU* would expect custom hardware. This still does not keep someone from hacking the OG hardware, but by definition it would be custom at that point.What do you think about having a discussion over skype or facetime? I like to keep all the discussion public, but some of what i am calling discussion details are really tedious for here. I just want to help ever how you think it should go.
If you are interested PM me.@lawrence_jeff the 2.2k worked like a champ as expected. So now I had confidence, I tried my 200 ohm and it worked. I will stay with the 2.2k, but not sure what I had wrong. Looks like we can use the single pin mode. Cool thing is we can pass the same pin for both parameters to the read_dianstance.
A couple of thoughts after quickly reading through the posts (sorry if I missed something you already discussed): there are a number of spare pins that OG doesn’t use, particularly if you use your own custom hardware, these can be easily freed up. For example, GPIO4, 5 (these are also the I2C SDA/SCL pins), GPIO16 (on OG circuit it’s tied to Reset in case some application requires putting OG to deep sleep, using GPIO16 tied to Reset pin can wake up ESP8266 from deep sleep, but since this is not used currently, GPIO16 can be freed for something else), GPIO2 (connected to ESP8266 module’s internal LED, but is free to use); in addition, GPIO13 can be freed if you don’t want buzzer.
Next, if you have N ultrasonic distance sensors, you only need N+1 pins, because you can have all of them share the same TRIG pin, but each having their own individual ECHO pin. Of course the problem is if these sensors are too close they can end up interfering with each other on the reflected signals, but if they are put far away or facing different directions, it should be fine. Be careful that since HC-SR04 requires 5V and ECHO pin outputs 5V, you should have a 1K resistor in line from each ECHO pin to ESP8266’s GPIO pin, this is enough to serve as a simple level shifter. There is a new type of sensor called HC-SR04P, that can be powered with 3.3V and won’t need the in line resistor.
Finally, IO expander as you mentioned is also a good idea. I am more familiar with the PCF8574 I2C IO expanader, which is very common and cheap.
Apparently ESP is 5v tolerant, at least according to CEO Mr Teo Swee Ann. That said, 2.2k resister on echo is a good idea if you don’t have a HC-SR04+
More… https://www.ba0sh1.com/blog/2016/08/03/is-esp8266-io-really-5v-tolerant/
I’m in the process of building a hobo twin sensor right now using one wire hack (and newping)… will report on results.
- You must be logged in to reply to this topic.