That's a very good idea!
[Release] HubDuino v1.1.3 - Hubitat to Arduino / ESP8266 / ESP32 / ThingShield Integration (ST_Anything)
I would expect the motor load to be in the 100-200 watt range. I did a little quick research and found it is common for the drum motor to be 120volt. That means it might show up on the other leg of the 240 volt circuit.
That's what I've found as well. However, with the first setup we did last weekend, I can't tell the difference between the two states (off and tumble) but the circuit I just made looks like it can. I did have to move the CT to the other leg of the 240. And just as you predicted, I am getting 5700 watts when heating, about 100-200 when tumbling only and under 20 when off. I'm running a full cycle of cloths now, so I'll have a graph with some data in about an hour.
Awesome! Great teamwork!
@Ryan780 cant wait to see the plots. Did you ever run the diode circuit connected to the power leg you are now using to see the motor consumption? I'm curious about relative performance of the two options. To get both versions running with similar output, try this scaling on the first circuit
static st::PS_Voltage sensor3(F("power1"), 15, 0, PIN_VOLTAGE, 0, 512, 0, 9600, 10, 100);
If the diode circuit does not pick up the motor running on the leg you are now using, I believe the cause is forward voltage of the diode being larger than the sensor output voltage at low current draw. Changing to the diode I originally recommended would lower the minimum current that could be observed, but it will never be as good as the voltage divider circuit used with Dan's new code.
Yeah, I was never able to get the tumble only to work with setup #1 unfortunately. But I got great results with setup #2.
It didn't capture when I opened the door for some reason. That was the true end of the cycle. The plateau at the end is the "Wrinkle Preventer" cycle.
I've been thinking about buying a bunch of 2 1/2 " horizontal blinds and automating them for months now. I bought a 3d printer so I could print the gearbox in this post:
The gearbox was designed for Home Depot blinds. Unfortunately, HD redesigned the the headrail. The new design has a radiused front profile and the result is that the bottom front of the headrail is 1/2 inch narrower that the top. Here are a couple of pics that show the problem:
Does anyone know of another compatible blind that will work with the 3d printed gearbox assembly? Baring that, for those of you using the HubDuino for blind control; which blinds are you using and how are you connecting the servo to the tilt shaft?
For what it's worth, I used this gear box as the basis for my vertical blinds. I used an online program called Tinkercad to modify this gear box to fit that headrail. I had no previous experience with 3d design. I figured it would take me about 4 or 5 times to get it right but I took some good measurements and hit it the first time. So, it's not outside the realm of possibility to modify this to fit your blinds. Since you have a 3d printer of your own, you can try it again and again as many times as you want.
I'll check it out--thanks.
It takes a little getting used to but they do have a tutorial. And as much as it pains me, if you do the tutorial, it is a lot easier to use. Quick tip...use the ctl shift and alt keys with your mouse moves and that can change the motion you make around the object you're working on.
Here's another I ran today. This is the low-heat cycle.
What I have now in RM is quite a few rules. I can detect if the cycle starts with heat or just tumble and then detect when the cycle is complete with either staying around 1400 for a period of time of instantly if it drops to 0.
Also, @ogiewon, you know that strange reading I was getting with nothing plugged in @ around 300? Well, when the cycle ends and everything is plugged in, it drops to zero and stays just about there. The highest I've seen it jump up at this point is about 2.2. So, I definitely think we have a solution here. Thank you @ogiewon and @VooDooFiveTwo!!! You guys have been such a huge help getting this working. I really didn't want to spend $100 on the HEM. And for $14 and parts I already had laying around the house, it now works perfectly!
This is great news, Ryan. Thank you for testing the new PS_Power class. I am happy to hear and see that it works well.
With Ryan's power project wrapping up, I've been thinking about details of my HVAC project.
I have been working out the hub Rule Machine
logic for controlling HVAC dampers using the new version of the EX_Servo class. I think it can be done, but the logic will be very convoluted. I am starting to think this would be easier to accomplish if the damper position calculations were moved to code on the hubduino.
That means I will need to create a new child class that receives a target temperature and the current temperature for a room from the hub. I want the hubduino to receive these two temperatures for each room and then calculate damper positions (servo angle) for each of the rooms in a coordinated manner. Coordination of the calculations across multiple child devices on the same hubduino is where I am a bit stumped. What is the best way to have local code execution on multiple child devices with data sharing? I am thinking a global variable array that contains target temperature, current temperature, and current damper position for each room might be a way to handle the data sharing. Do you have any thoughts on ways to tackle this?
Edit: Maybe dropping the the child device architecture and reverting to the original Smartthings Arduino approach is a better way to go. If I consider this to be one device with multiple inputs and outputs, the microcontroller code is a lot less challenging. The issue will become creating a device on the hub that can handle all input and output variables.
You could simply add your custom “local processing” logic to the sketch’s loop() routine. From there you could command each of the devices as necessary. This way you can maintain as much global state as required directly in the sketch.
This makes sense for a special, purpose built device. HubDuino is designed as a somewhat rigid structure for integrating simple devices.
I'm torn between keeping it simple on the hub end of things while maintaining maximum flexibility for calculation and sharing of data between devices on the Hubduino. If I keep the child device architecture and place the calculation code in the loop function of the sketch, how would I need to declare an array that can be accessed within each child instance and within the loop function? How much time can I consume for each pass of the loop function without causing communication issues between the Hubduino and hub?
Each Servo device would not need access to any of the data stored within the sketch. The custom code in your sketch would simply issue commands to control the servos in the exact same way the Hubitat hub does already. Just issue a call similar to the one below:
This tells ST_Anything's Everything class that data has been received from the communications library (either the old ThingShield or the newer LAN/WiFi supported hardware.)
You can fairly safely consume 500ms to 1000ms without any adverse effects based on my testing.
Are you planning on collecting the temperature data via the HubDuino board? Or other sensors in the rooms? If the HubDuino board has the data locally, it would still need to get the Target data from your Hubitat hub, correct?
Perhaps you should consider writing a custom Hubitat App that runs on the hub to handle all of the data analysis and control, and leave HubDuino to the task of collecting temperature data and controlling the servos? Since Hubitat runs local, no worry about a cloud outage taking the system down...
Temperature info will be coming from sensors in the rooms via the hub, not from sensors attached to the hubduino. Servos will be the only devices connected to the hubduino. The reason I would like to coordinate the dampers is to direct the most air to rooms that are the farthest away from target temperature.
I use a programmable thermostat (Lennox iComfort) that is integrated with HE. I do not control it via the hub, but do access data about setpoints, current temperature at the thermostat, and operating mode. The issue I am wanting to address stems from large target temperature changes that occur when the thermostat program exits a setback condition and tries to adjust temperature about 10 degrees F. During this large temperature adjustment, some rooms reach target faster than others so balancing of the duct dampers is required. I can get it set up pretty well for cooling mode or heating mode, but the damper positions are different for each of those modes. It usually takes a lot of manual interventions as the seasons change.
My goal is to be able to set a damper position based on more than just the temperature error for the room it is connected to. I would like to prioritize rooms that have the highest temperature error. This prioritization calculation is what drives the need for sharing data for all the rooms.
It really feels like a custom Hubitat App might be your best bet. This gives you one place to control all of the logic, and easily tweak it as needed. The App would have access to all of the necessary data from the temperature sensors and thermostat, and can send servo position commands to each vent.
I'm not so good with Groovy. Sounds like I need to learn it.