[Release] HubDuino v1.1.7 - Hubitat to Arduino / ESP8266 / ESP32 / ThingShield Integration (ST_Anything)

community_app
community_driver

#735

I am actually not using it at all. I use an IoTaWatt to monitor my home's power usage.

One thing to be aware of, is not matter what CT you use, the output from your CT circuit must be a voltage that can be read by the analog input of the microcontroller board.

The specific CT you linked above clearly states "This sensor does not have a load resistor built in, so in most cases it will be necessary to place a resistor across the output to convert the coil's induced current to a very small measurable voltage."

Just be careful as you can easily fry the Arduino if the CT circuit is not designed correctly.

I have used the following in my testing of the PS_Power device. This specific model CT does have the burden resistor built-in. (Note: same company sells versions without the burden resistor as well.)


#736

I'd love to see this capability added. @ogiewon: I'm not sure if you've seen this...

It uses small and inexpensive stepper motors instead of a 180 degree high torque servo. In the video, he's running 3 stepper motors connected in parallel controlled by a single ESP8266 and a single 12V 2A power supply. Excluding the 3D printed parts, cost is approx $10 per blind. The real draw for me is that the stepper overcomes many of the issues of doing this with a servo:

  • difficult to manage open close speed without motion becoming super jerky
  • 180 degree servo rotation is insufficient for true full close/full open operation
  • servos are irritatingly noisy
  • powering more than one servo from a single power supply is difficult without a high amperage supply since each servo can draw close to 2A
  • I'm sure I'm forgetting a couple of others

I tried automating a couple of blinds with servos but ditched the project because of all of the above. My vacation home has a bank of 3 large (42" X 70") mulled windows. Each has a 2 1/2" horizontal blind and the high torque servos I was using did not like it when I attempted to fully close the blinds.

I haven't tried the stepper motor setup outlined in the video--like an ass I left my 3D printer at the vaca home and I won't be back there until November.

Any chance you'd consider adding stepper motor and the blind capability to Hubduino?


#737

There's always a chance! :wink: It's just not very high on my list, currently. I have zero blinds or shades in my own home that I can automate, thus I have very little personal incentive to work on this. Just being honest! :stuck_out_tongue: My house has wooden plantation shutters on every interior window, with no way to automated them and have them look decent afterwards.

I watched the video and found it very interesting... however I think the author glossed over some very important issues, like how to 'home' the stepper motors. This is not a trivial task, and it is very important to know the position of the stepper motor. Otherwise, it is too easy to over-travel through one of the endpoints, causing damage to the motor/gear-box/blinds. A simple power blip to your home and these devices will all lose their position tracking.

The beauty of the servo motors is that they have built-in position feedback. Steppers, while often more powerful, have zero feedback. In fact, when a stepper motors stalls, there is still no feedback.

So...that's where my head currently is with regard to stepper motor support within HubDuino. I'm not saying it will never happen...just that its not a priority for me. If someone else wants to try tackling it, I am always willing to review Pull Requests to HubDuino/ST_Anything.


#738

I fully understand your position and appreciate your honesty :slight_smile: I hadn't really considered the homing aspect of the stepper motors, which, in a typical application which would probably be handled with a limit switch or sensor--ditto for an over travel limit. Clearly, this isn't an arrangement that can easily be incorporated in a blind headrail.

The beauty of the servo setup is its simplicity. Unfortunately, I think it's a poor fit for most setups. Ideally, I'd want all of the blinds on the mulled windows to operate in sync and it's not something I think can be accomplished with multiple servos since they can't all be driven at once without a prohibitively large/expensive power supply. Also, I'd like to be able to gradually alter the blind angle based on the time of day. My servos seemed to have issues with small position movements and frequently oscillated back and forth when trying to move in small increments.

The search for the perfect automated blind solution continues!


#739

Sorry, I've taken a LOT of blows to the head (some recently) and have a hard time figuring things out for myself sometimes. Actually, I just wasn't looking in the right places and tried jumping ahead. After re-reading the ReadMe file it mostly did turn into an RTFM issue. I was trying to download the code as a zipfile at the wrong level. Also, I hadn't installed the correct driver for the USB TTL UART cable. Then I misread instructions on the LinkSprite website on how to set the board to program.

Now the board happily will talk to my network. [Edit:] I just got the device working the way I want it to a few minutes after reading this ST_Anything/HubDuino at master · DanielOgorchock/ST_Anything · GitHub

I now have a 4 outlet "smart plug". I used 2 duplex switches a few wire connectors, a scavenged 5v wall-wart (old 800 ma phone charger) and a 2 gang electical box (https://www.homedepot.com/p/1-2-in-2-Gang-FSE-Box-R5133380/202043395). I also bought new 3-prong 110v plug end and 2' of 3 wire power cord. (I was going to use this one but it was too expensive https://www.homedepot.com/p/InSinkErator-Power-Cord-Accessory-Kit-for-InSinkErator-Garbage-Disposals-CRD-00/100041635)


#740

I am adding some DHT22 sensors to the sketch and Hubdino. A quick question on naming these things. Currently I have this line for one of them in my sketch.
static st::PS_TemperatureHumidity sensor2(F("temphumid1"), 60, 40, PIN_TEMPERATUREHUMIDITY_1, st::PS_TemperatureHumidity::DHT22,"temperature7","humidity7");

Can I manipulate the entry thus and get the DHT22 named the way I want it right off the bat?
static st::PS_TemperatureHumidity sensor2(F("temphumid1"), 60, 40, PIN_TEMPERATUREHUMIDITY_1, st::PS_TemperatureHumidity::DHT22,"MBR Temp","MBR Humidity");

Since I am adding and changing things around would it be better if I deleted the HPE and let it automagically repopulate the child devices?

Thanks


#741

No, unfortunately you cannot. Those last two names ("temperature7","humidity7") are what is used by the Parent Driver to know how to create the child temperature and child humidity devices.


#742

Thanks Dan. That explains why it doesn't work. :))


#743

I am using one of those to monitor my electric dryer. I don't think that the measurements that I'm getting are accurately linked to actual power usage but I played around with the numbers enough to be able to get something that tells me when the dryer is finished, which is all I really wanted. I had to do a little wiring magic to get it to work. I've been trying to dig up the post where someone helped me wire mine but I can't find it at the moment. If I do, I'll pm it to you.


#744

What you need to do is build a multi-device device like the garage door control. You have one pin for the stepper down control, one pin for the stepper up control, one pin for the contact sensor up sensor, and one for the contact sensor down. You mount a contact sensor where you want the roller to stop on the way up and another at the down position. That way you're only traveling until you get positive feedback from the sensor. Do you think something like that would work for a stepper motor? (and no, i'm not asking you to build anything...I'm just asking as a concept do you think that would work better?)


#745

Yes, that’s probably what it would take... Having inputs for clockwise overtravel, counterclockwise overtravel (and possibly a home limit switch) would help make things robust and reliable. This is how we design motion control systems at work.


#746

@ogiewon I have one sensor that I am getting this error on. I have two of these that are identical but only see this on one of them. This is the humidity child. Both of these are on a NodeMCU with a BME280 for temp, humidity and pressure and a BH1750 for illuminance. The only difference is that one is in the back yard farther from the wifi than the other that is inside my house. This did not happen at first but started after a while. Is it possible it's due to lower signal?


#747

I believe that error is because the BME280 Arduino library is returning "nan", which means "not a number". This is throwing the error in the Child Humidity Driver as it is trying to convert "nan" to a floating point number.

So, not a WiFi issue. Possibly a wiring issue, or maybe a weak power supply to the NodeMCU board, or possibly the BME280 is defective? I truly believe the problem is somewhere within the NodeMCU and the BME280.


#748

@ogiewon That makes sense. I have another BME280 that I will try replacing with. I have already swapped the NodeMCU board with my other with the same results. I really thought I would have other issues as well if it was wifi but I didn't know what the "nan" meant. Thanks for the quick reply!


#749

ALL - I have finished my initial testing of a change requested by another user to the IS_DoorControl device. You can now determine in the Arduino Sketch if you’d like the output to behave as a momentary output (default) or as an on/off switch output (i.e. Open = output ON, Closed = output OFF, instead of a simple momentary output toggle)

I have uploaded to my GitHub repository the following files. Note - this is a matched set of files. There is no need to update the Child Door Control driver unless you have updated your microcontroller with the updated IS_DoorControl library files first.

Arduino ST_Anything library files

  • IS_DoorControl.h
  • IS_DoorControl.cpp

SmartThings Groovy Device Handler

  • Child Door Control

In your existing sketch, you will need to add an additional parameter when creating the device. Here is an example code snippet where the first door control device uses momentary (default, if no parameter is supplied) and the second door control device uses an on/off switch style output.

  static st::IS_DoorControl sensor1(F("doorControl1"), PIN_DOORCONTROL_CONTACT_1, LOW, true, PIN_DOORCONTROL_RELAY_1, LOW, true, 1000, 1000);
  static st::IS_DoorControl sensor2(F("doorControl2"), PIN_DOORCONTROL_CONTACT_2, LOW, true, PIN_DOORCONTROL_RELAY_2, LOW, true, 1000, 1000, false);

And here is the documentation for all of the parameters…

//			  Create an instance of this class in your sketch's global variable section
//			  For Example:  st::IS_DoorControl sensor3(F("doorControl1"), PIN_CONTACT_DOOR_1, LOW, true, PIN_RELAY_DOOR_1, LOW, true, 1000, 1000, true);
//
//			  st::IS_DoorControl() constructor requires the following arguments
//				- String &name - REQUIRED - the name of the object - must match the Groovy ST_Anything DeviceType tile name
//				- byte pinInput - REQUIRED - the Arduino Pin to be used as a digital input
//				- bool iState - REQUIRED - LOW or HIGH - determines which value indicates the interrupt is true
//				- bool internalPullup - REQUIRED - true == INTERNAL_PULLUP
//				- byte pinOutput - REQUIRED - the Arduino Pin to be used as a digital output
//				- bool startingState - REQUIRED - the value desired for the initial state of the switch.  LOW = "off", HIGH = "on"
//				- bool invertLogic - REQUIRED - determines whether the Arduino Digital Output should use inverted logic
//				- long delayTime - REQUIRED - the number of milliseconds to keep the output on
//				- long numReqCounts - OPTIONAL - number of counts before changing state of input (prevent false alarms)
//              - bool useMomentary - OPTIONAL - use momentary output (true) or standard switch (false) (defaults to true)

NOTE for ALL Users: The new groovy Device Handler and Arduino code are somewhat of a matched set. The new Child Door Control Driver should only be used after updating and deploying the Arduino code with the new IS_DoorControl.h and .cpp files.


#750

Good call @ogiewon on the bad sensor. I got around to replacing that BME280 this evening and all is working again.


#751

I don't have any jerky Motion with my servos
I have 270 degree servos and they just reach each limit (just)
The servo is quiet if opening slowly. Only noisy if opened within a second which isn't required.
The servos can turn one after each other if power isn't enough to power all at once.

Not saying a stepper isn't a good option, but I don't see any of your problems with ones I recently installed.


#752

I'm glad your setup works for you and I'd be curious to know the size of your blinds (width, length, and slat width).

For me, a high torque 180 degree servo labored at slow speeds and was basically unusable. At full speed, the gearing noise is pretty irritating to me. Maybe if I invested in expensive 270 degree high torque servos the first 3 bulleted items would be a non-issue.

But as I mentioned in my post, I have a bank of 3 mulled windows. Operating the blinds one at a time to overcome the power supply issue sets off my "that's not the way they should work" OCD.

I haven't tried the stepper motor setup yet but I've already thought about using open and close limit switches to overcome the stepper motor homing issue. Unfortunately, my blinds and 3D printer are 600 miles away so I won't have a chance to work on this for another 3 months or so.

Is a stepper motor drive a better solution? Beats me, but more options are more better :slight_smile:


#753

My blinds aren't very wide as I have awning style windows (only about 1m wide), but they are about 2m high though. Slats are 50mm slats.

Mine weren't overly expensive. I can find the models of what I got if you like? I previously used a more reputable 180 degree servo for a trial, but that tended to jitter and not rotate far enough.

Edit: just checked as it was while back I bought them and only just fitted them. They weren't cheap @ 22 aud (15 usd) but happy with them. They are DF Metal Geared 15Kg Standard Servo 270° (DSS-M15S)

Fair enough. If mine are rotated at full speed then they turn one after the other due to the small delay in the porgram, howveer if I turn slowly which is very smooth and much quieter (as in barely audible if they take 10 seconds to open), then all servos look to turn in sync. My power supply is a 3A for 3 servos and seems OK. Although my windows aren't very wide, just reasonably tall.


#754

I hope that soon there will be an opportunity to use stepper motor with my project. otherwise it has been on the shelf for a very long time. need to finish it ... Thanks