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

community_driver
community_app

#487

Thank you so much Dan. It will be a couple of days before I get it all hooked up. I will let you know.

Thanks again


#488

So my settings for using pins 10, 11, 12 would be:

 static st::PS_DS18B20_Temperature sensor1(F("temperature"), 60, 0, 10, false, 10, 6, 1);
 static st::PS_DS18B20_Temperature sensor2(F("temperature"), 60, 0, 11, false, 10, 6, 1);
 static st::PS_DS18B20_Temperature sensor3(F("temperature"), 60, 0, 12, false, 10, 6, 1);

#489

Not quite... see the changes below. Your example above would attempt to read and send all 18 temperatures at the exact same time, every 60 seconds. Also, your example would send updates for "temperature1" through "temperature6" three times with conflicting values. We want all 18 temperatures sent as "temperature1" through "temperature18", each with a unique sensor value.

static st::PS_DS18B20_Temperature sensor1(F("temperature"), 60, 0, 10, false, 10, 6, 1);
static st::PS_DS18B20_Temperature sensor2(F("temperature"), 60, 5, 11, false, 10, 6, 7);
static st::PS_DS18B20_Temperature sensor3(F("temperature"), 60, 10, 12, false, 10, 6, 13);

#490

Ahh I see what I did. I copied and pasted and forgot to make the changes. I assume that the sensor1, sensor2, sensor3 need to be enabled


#491

Yes, make sure you add all three sensors to Everything as shown below.

  //*****************************************************************************
  //Add each sensor to the "Everything" Class
  //*****************************************************************************
  st::Everything::addSensor(&sensor1);
  st::Everything::addSensor(&sensor2);
  st::Everything::addSensor(&sensor3);

#492

So doing that didn't change. Thanks


#493

Hey @ogiewon have you had major trouble with your Hubduino devices recently? I have had a hell of a time keeping commands going to them. They seem to get disconnected like crazy recently. Do you know of any change that would have caused this? Thanks!

EDIT: It might have something to do with the new servo library. I have had to replace one board already and I think a second one is about to go too because it is failing at boot to come to the boot settings.

Its so bad that yesterday, my blinds too so long to move when I left that they set off my alarm because the motion was after the 60 second exit delay.

Today I'm seeing a good 8 seconds between action called and device response.

dev:964 2019-03-13 07:59:56.500 pm debug   parse(servo 100:180:1000) called

dev:964 2019-03-13 07:59:48.271 pm debug  setLevel >> level: 100, rate: 1000

#494

I am not aware of any changes. My devices are working normally.


#495
 static st::PS_DS18B20_Temperature sensor1(F("temperature"), 60, 0, 10, 
false, 10, 6, 1);  //DS1820 Sensors 1 -6
static st::PS_DS18B20_Temperature sensor2(F("temperature"), 60, 5, 11, 
false, 10, 6, 7); //DS1820 Sensors 7 -12
static st::PS_DS18B20_Temperature sensor3(F("temperature"), 60, 10, 
12, false, 10, 6, 13); //DS1820 Sensors 13 -18

When I am trying to verify and complie I am getting a
no matching function for call to 'st::PS_DS18B20_Temperature::PS_DS18B20_Temperature(const __FlashStringHelper*, int, int, int, bool, int, int, int)'

My libraries are all up todate AFAIK


#496

Please double check that you have the latest versions of the "ST_Anything_DS18B20_Temperature" library.


#497

I am sure that is probably the issue. I just need to remember where and how to make the updates. :grinning:.


#498

Updating the Library did the trick. I won;t be able to put it in action until this weekend, Thanks Dan


#499

What board type are you using? Is your issue only on boards that have servos connected?

My servo implementation is still on the test bench, but seems stable now that I sorted out separate power supplies for the servos and board. Separate supplies helped stability, but I still had issues with extended run times. The last issue I had was a cheap 9V wall wart connected to the board power plug (not USB port). It would cause the MEGA board to get hot in the area of the voltage regulator. After about 8 hours, servo response became erratic and I saw what appeared to be reboots via serial monitor. I checked unconnected voltage out of the wall wart and found it was near 14 volts despite a label rating of 9V DC. I'm now powering the board via USB port and get stable results over 3-4 days. I have not tried longer uninterrupted runs as I am still experimenting with parameters, but total run time of this hardware setup is about 3 weeks.

I have a better quality 9V supply connected to the power port on another Mega that does not have servos attached. That board has been very stable for months and it runs cool. Response is generally within a 1-2 seconds on interrupt sensors and outputs. I'm pretty sure I updated all the hub code for devices attached to that board when the servo architecture changes were implemented.


#500

I am using Wemos D1 mini's for all of them. And I always run a parallel power to the board and the servo. In general, none of them are giving me any trouble. The one that is is the one with a different servo. It's a LewanSoul LD-20MG. The PMW specs are a little different than the MG996 or MG995. Here are the details:

Pulse Width: 500~2500
Duty Ratio: 0.5ms~2.5ms
Pulse Period: 20ms

What I am seeing now, with the default settings is that even on boot, the servo will move a little and then keep stuttering back and forth slightly even after the "disconnect" was supposed to happen. I haven't pulled the servo off the window yet as that isn't an easy thing to do but I can if I have to. It is a 6.5-7.5v servo, so i have 12v going in with 2 buck converters, 1 at 5v for the board and one at 7v for the servo. I have confirms voltages for both with a voltmeter.

I can take a video of the "stuttering" if it's not clear what I mean is happening.

UPDATE:
So, I pulled the servo off the wall and brought into into the "lab" to do some further testing. It is definitely a power problem. Either I am getting interferance from having two buck converters in the same circuit or have something crossed somewhere because when I power the servo off of a direct supply, it works fine. Part of the problem also is that it pulls over 1A. I may have to look at running two separate power supplies, one for the board and one for the servo.


#501

Well, another 4 days of work on these blinds and still not working correctly. I really don't understand what is going on. The servo will just move on its own long after the detach is sent. The only thing I can possibly think is that its a power problem. So, since this is an "odd" servo, I will be ordering a 7v power supply to give that a try. If that doesn't work, I will be ripping the whole setup out. This stuff really shouldn't be this hard!


#502

I don't have one of those particular servos on hand to test, but can offer a couple things for you to look at.

It is not common, but some digital servos maintain last commanded position when the signal pulse train is interrupted. I could not find this called out in the specifications for the LD-20MG, so some experimentation will be needed to confirm the servo type. After the detach command is issued, can you move the servo by hand to see if it trying to hold position?

Have these two boards literally stopped working, or are they just glitchy in this application?


#503

One board completely dies but I can't say for certain why. The 5v regulator on the board now just gets insanely hot about a minute or two after plugging it in and it never registers on my PC.

With the servo not powered on, I can't move it at all by hand. Have to send command to it in order to get it to move at all. The buck converter I was trying to use blew up when I was removing it from the blinds (shorted out on the metal rod) so I have no other way of testing it until I get the power supply next week. I'll tell you think though...I'm considering now even getting it at this point. I've become a little frustrated with Hubitat in general. None of my motion lights trigger even close to as fast as they did on SmartThings anymore all of a sudden. I keep sinking more and more money into it and all it does is waste my time and piss me off. So, I appreciate your help but I think I'm done with it at this point. It's just not worth it in the end.


#504

If you decide to give it another go, let me know. I think that particular servo might have some non typical characteristics that require special handling.


#506

It says it is a standard servo. So, I don't know why you would think that. Everything was working fine before the "improvements" to the servo library were made. That's what started everything now working incorrectly..


#507

The motion after detach is what makes me think it is the type that actively maintains position after detach. Are your blinds with 996 servos still working as expected?

Given the start of your troubles was the servo driver code update, I wonder if the slow motion feature is the source of the issue. You could isolate that feature by setting duration to 0 seconds.