[Suggestion] PWM for Led driver dimming

[leoneo]

Hello Kyle,

I would like to control the brightness of 3 led strips (red, blue, white) in the time. For example function 1 : day 1 = 10%; day 2 = 15%; day 3 = 20 % ... day 15 to day 30 = 100% function 2 : sunrise start at 6:30AM with 0% to 100% in 30min / sunset start at 8:30PM with 100% to 0% in 30min.

There are led drivers dimmable with 0-10Vc PWM input and with a 0-5V 0-10V PWM Converter Module it is theoretically possible with the Raspberry Pi to control the brightness. https://raspberrypi.stackexchange.com/questions/298/can-i-use-the-gpio-for-pulse-width-modulation-pwm http://www.meanwell.com/productPdf.aspx?i=300 http://www.uctronics.com/0-5v-0-10v-to-0-100-voltage-to-pwm-converter-module.html

Please can you add a PWM output function in Mycodo ?

Thanks Leo

[wangine]

You have a clue ? I think i messed up the system .

[kizniche]

Well, that's not a very descriptive error, lol

Do this... in Mycodo/mycodo/controller_relay.py, add this line after line 686, so the code looks like this:

        except Exception as except_msg:
            self.logger.exception(1)
            return 1, "Add_Mod_Relay Error: ID {id}: {err}".format(
                id=relay_id, err=except_msg)

Then restart the daemon, sudo service mycodo restart and do what you did to get the error, again.

[kizniche]

There should then be the full exception traceback in the daemon log.

[wangine]

yea

`2017-07-20 04:41:55,475 - mycodo.relay - ERROR - 1
Traceback (most recent call last):
  File "/var/www/mycodo/mycodo/controller_relay.py", line 654, in add_mod_relay
    if self.relay_state(relay_id) != 'off':
  File "/var/www/mycodo/mycodo/controller_relay.py", line 845, in relay_state
    if self.pwm_state[relay_id]:
KeyError: 1
2017-07-20 04:45:48,072 - mycodo.relay - ERROR - 1
Traceback (most recent call last):
  File "/var/www/mycodo/mycodo/controller_relay.py", line 654, in add_mod_relay
    if self.relay_state(relay_id) != 'off':
  File "/var/www/mycodo/mycodo/controller_relay.py", line 845, in relay_state
    if self.pwm_state[relay_id]:
KeyError: 1`

[wangine]

I wonder , you can acces my RPi ? adress : wangine.go.ro user : test pass : 123456 I just forward my rpi IP on 80 port to my DDNs

[kizniche]

Nope. SSL will be port 443, also.

There aren't any errors when the daemon starts? And I assume those errors occur when you try to save the configuration.

[wangine]

yes same error. I difficut for me to focus, is 4.50 PM here, i just wait you because i know you are active arown that hour. Should enable 443 forward on my router ? I can doit in 10 seconds , UDP ?

[kizniche]

I found the issue. Making a commit to fix in a moment.

[kizniche]

Oh, you meant AM, not PM. Yes, that's too early for me, for a weekday. That latest commit should fix the issue.

[wangine]

working now . You can login in my RPi . I just forward 443. I test on my phone out of network

[kizniche]

I'm in. I changed the "test" user password for security, so no one else can use it.

[kizniche]

Use the update instructions in this comment and see if that fixes it.

[wangine]

security dont matter , RPi is temporary for testing. Power line are OFF, so only sensors are active , OK, I give a try now

[wangine]

OK.will work . The user remain active for you , you can test sensors , i add the last one sht25. I change to 30sec read data. maybe 15sec wasn't good for them. I will test tomorow is altmost morning (after i will sleep 4 hours ) on my service and i made a test board for AC and DC . You do a great job for moment . Interface are cool and easy to configure.. I wish you good day or a night

[kizniche]

I think perhaps adding a Minimum (and/or Maximum) allowed duty cycle to be set for PWM PID controllers could be beneficial. I'm getting weird results at duty cycles of <= 2. This could also be useful for a number of applications.

[wangine]

Yes , will be . I can made more tests on other PI next hours on my service about PWM. My home RPi stoped with strange error after 40 minutes . I just seen daemon stoped when i wake up. User is active , You can figure out what's going on. If i move the sensors on my old RPi will run without error.

[kizniche]

I changed the database schema in one of the latest commits, so after you update, you'll need to delete /Mycodo/databases/mycodo.db and then visit the web interface to generate a new database with the correct schema, before starting the daemon sudo service mycodo start

My testing last night had PWM and PID working fine, as far as I could tell, so let me know of any issues.

[kizniche]

I just added better error reporting to all sensors, so if you could update and wait for the error to happen again, there should be a more detailed error in your log to identify the issue.

[wangine]

I testing right now on other RPi , with a simple PID and a laptop fan controlled by PWM to cooling the CPU , sensor is internal RPi. I still wait . Lover direction is working?

[kizniche]

Lower should be working. I've only been testing the raise option, but lower should theoretically work.

[wangine]

Yea , raise work, lower not. Also like a suggestion, should put limit of math between 1-100 . We dont need 21,233333333 duty cycle. Is unuseless stress for RPi. In C, i use like example: for float operations 32.0f * 1.663 = 53.3 not 53.3216 , result is rounded I dont know how that's is doing in python, but you know for sure. Also i didn't notice anything wrong below 2 duty . in 1000 samples at 10kHz no any pulse miss or clock fail. Still graph and live page i thing was not updated

[kizniche]

I'm fairly sure there isn't any benefit to rounding, at least with Python. It may in fact require more computation to do so, considering the input value is a float anyway, and rounding a float would still produce a float as the input. Where did you get the 21.233333333 value?

I just finished getting graphs and the live page to work and pushed a commit.

[kizniche]

Graphs look like they're working nicely. Lower output should now work, but I haven't tested it.

[wangine]

When PID is active if you look on relay stats we can see what value duty cycle have. Yeaa graph look great . I can do any test right now because i formated my RPi again with fresh jessie image. Is strange , wasn't succes on clean install sudo apt-get install -y jq cd ~ curl -s https://api.github.com/repos/kizniche/Mycodo/releases/latest | \ jq -r '.tarball_url' | wget -i - -O mycodo-latest.tar.gz mkdir Mycodo tar xzf mycodo-latest.tar.gz -C Mycodo --strip-components=1 rm -f mycodo-latest.tar.gz cd Mycodo/install sudo /bin/bash ./setup.sh I dont know what happen , also i try to install tle old orhive of Mycodo just to check if why daemon still stop without reason. I'm still trying. Mycodo-master03.10.2016.zip That was the best version without any bug, still running on other RPi from that date without any error. I dont know what happen

[kizniche]

Yeah, I thought that would be a nice feature to see what duty cycle the pin is outputting on the output page. It's very helpful if you don't want to load the whole graph page. The outputs page is currently set to a 6 second refresh period.

The install instructions in the README will download the latest release, not the latest commit from the PWM_support branch. To install from the PWM_support branch, you'll have to use the instructions in this comment.

[kizniche]

I'll be releasing 5.1.0, which includes the PWM support, soon. I just want to make sure there aren't any other bugs lurking. I at least want to test the PWM lower output myself.

[kizniche]

...As well as probably add some more PID options for PWM, to allow selecting what duty cycle calculation method to use, and maybe another option to select how the min/max options operate. So far, I think there can be two min/max methods that could be useful:

1. Always On: If the PID output is below the min or above the max, set the duty cycle to min or max, respectively.

2. Allow Off: If the PID output is below the min or above the max, set the duty cycle to 0 (turn off PWM).

[kizniche]

The latest PWM_support version has a lot of new sensor error reporting. So, if you experience an error with that version, we may be able to find the issue and correct it to stop the daemon from crashing.

[wangine]

The first option with gradualy increase should be beter because controll can come almost linear and perfect if PID is tunned right. Also lower dont work for sure because i tested today on other PI with new image and Mycodo , Rise work good. Anyway the time will decide . Still great work

[kizniche]

I fixed the lower PID output 30 minutes ago with commit 37627aae

[wangine]

Cant try right now, i still install the old release. I want to be sure any hardware and sersors are OK 100% .That release like i say still running from last year, so i hope will finish without errors

[wangine]

Running setup.py bdist_wheel for numpy: still running... To long LOL. I try to say about duty cycle , not the math to be rounded, only to convert the float value to integer 0-100 . Still i dont understand how system can put on duty cycle 40.33 . Its imposible in my mind, that require EX: running at 20kHz a 40.33 duty cycle PWM need to be able to compute 2MHz , because teoreticaly we move under, with 2 zecimals . Also sorry for missunderstanding , english is not my mother language and i'm not realy good at.

[kizniche]

Oooouch! It's a version where it has to compile numpy. My condolences 🙏

Okay, I understand now. So, one decimal place should be sufficient?

[wangine]

No , because actualy to duty cycle to be set at 20kHz with one decimal PWM need to be capable to run at 200kHz. No reason of that . Just rounded is perfect , like 32 or 67 duty . Mycodo was running great with relays (is like a 0 and 100% duty cycle teoreticaly the relay modulation) , with PWM we increase ability with 1000%. I thing is more than enouth on any purpose. If you want to see the real computation , that's the different thing and can be nice to see. Yea thanks for support about numpy ./setup.sh: line 82: /home/pi/Mycodo/mycodo/scripts/crontab.sh: Permission denied I get a error anyway

[kizniche]

Are you running the setup as root?

[kizniche]

Not sure about that error, if it's not the current version of Mycodo, I don't really know how to investigate it, unless you have a commit I can reference to see the state of the code at that time.

[wangine]

LOL no , was just a joke , i try to install the old Mycodo version , dont bother with . No , i run the setup as pi user. I just try to see if my board is ok and all my sensors . Is the best debug with knowing working code

[wangine]

I canot install the old Mycodo. I dont know why . Still on last release i has some trouble. Twice a new fresh install , impossible to jesie full, . Verry hard on lite and only with PWM update . PWM seems working. I canot test right now on real hardware to see how he do the job, but i look in daemon log soon i install and i configure random PWm relay.

2017-07-21 03:27:42,910 - mycodo.pid_1 - INFO - Activated in 306.6 ms
2017-07-21 03:28:04,460 - mycodo.stats - ERROR - Could not send anonymous usage statistics: {"error":"timeout"}
Traceback (most recent call last):
  File "/var/www/mycodo/mycodo/utils/statistics.py", line 318, in send_anonymous_stats
    client.write_points(formatted_stat_dict)
  File "/var/www/mycodo/env/local/lib/python2.7/site-packages/influxdb/client.py", line 456, in write_points
    tags=tags, protocol=protocol)
  File "/var/www/mycodo/env/local/lib/python2.7/site-packages/influxdb/client.py", line 506, in _write_points
    protocol=protocol
  File "/var/www/mycodo/env/local/lib/python2.7/site-packages/influxdb/client.py", line 302, in write
    headers=headers
  File "/var/www/mycodo/env/local/lib/python2.7/site-packages/influxdb/client.py", line 259, in request
    raise InfluxDBServerError(response.content)
InfluxDBServerError: {"error":"timeout"}

2017-07-21 03:28:13,293 - mycodo.relay - WARNING - PWM duty cycle must be a positive value
2017-07-21 03:28:43,175 - mycodo.relay - WARNING - PWM duty cycle must be a positive value
2017-07-21 03:29:13,264 - mycodo.relay - WARNING - PWM duty cycle must be a positive value

and error stil going down . Of course duty can't be negative value. I assume that happen in PID integrator. I dont get it. Even on lower is the same , possitive value raise duty 100 75 50 25 --- setpoint --- 25 50 75 100 lower duty

[kizniche]

Try this and see if it fixes your influxdb issue.

[wangine]

Yea , maybe that was the problem with my sensors and stop daemon , because every time i look in daemon log, InfluxDB became first error and below my sensors stop to read .

[kizniche]

It was probably a combination of the sensor controller not being able to write to the influx db and the PID controllers, web UI, etc. not being able to read the measurements in the influx db. Nothing directly takes measurements except for the sensor controller, to ensure measurements aren't interrupted by a process. Everything else feeds from the influxdb.

[wangine]

Yes , you assume right .

2017-07-16 13:31:51,415 - mycodo.pid_1 - WARNING - No data returned from influxdb
2017-07-16 13:32:22,801 - mycodo.sensors.sht1x_7x - ERROR - SHT1x7xSensor raised an exception when taking a reading: (113L, 255)
2017-07-16 13:36:22,517 - mycodo.sensors.sht1x_7x - ERROR - SHT1x7xSensor raised an exception when taking a reading: (214L, 255)
2017-07-16 14:10:45,435 - mycodo - INFO - Received command to terminate daemon

Like that error became. I will test tomorow on a real hardware the PWM with hard stress for him...

[kizniche]

I fixed the lower output with the latest commit and have confirmed both raise and lower now work as expected. Here's a graph of the response to me heating the sensor with my finger and then letting go for it to return to ambient temperature.

[wangine]

Look realy nice. Unfortunately my daemon still stop . Was a fresh install on jessie lite , i dont know what is wrong. The same error on many lines below.

  File "/var/www/mycodo/mycodo/sensors/sht2x.py", line 118, in read
  File "/var/www/mycodo/mycodo/sensors/sht2x.py", line 88, in get_measurement
  File "/var/www/mycodo/env/local/lib/python2.7/site-packages/smbus/smbus.py", line 56, in __init__
  File "/var/www/mycodo/env/local/lib/python2.7/site-packages/smbus/smbus.py", line 83, in open
IOError: 24
2017-07-21 13:06:46,090 - mycodo.sensors.raspi - ERROR - RaspberryPiCPUTemp.get_measurement() method raised IOError: [Errno 24] Too many open files: '/sys/class/thermal/thermal_zone0/temp'
2017-07-21 13:06:48,952 - mycodo.sensors.sht2x - ERROR - SHT2xSensor raised an exception when taking a reading: 24

It is weird because daemon is stopped but sensors still measure on live page. When i install Mycodo i get a single error , i canot expand file system. Any clue?

[kizniche]

IOError: [Errno 24] Too many open files

This is a new, rare error, and is a duplicate issue of #254 that I have never experienced myself or been able to replicate.

[kizniche]

i canot expand file system. Any clue?

If you cannot expand the filesystem, then do not continue with the Mycodo install. THere will be problems. You need to be able to expand the filesystem to have enough space to do anything on the SD card or linux.

[wangine]

First off all. I try to put Mycodo on fresh jessie install. I notice on first boot of RPi after write image , short message The system memorry will be resised,,, reboot after i get error trying to expand filesystem and install mycodo. Trying to install old version (that version still running fron last year on other RPi) Many errors , also trying to write permissions of a file. So far so good , alot of frustration. I found a old Jessie full image on my other PC, so i put it on SD card. Strange when i boot that message with resize file system didn't appear. So i go on expand file system and i get succes. I again to install last version. without succes,./setup.sh: line 123: /home/pi/Mycodo/mycodo/scripts/update_mycodo.sh: Permission denied so i write manualy the file permisions in a tree. After that i get succes install. Running from last night without daemon error or influxDB error. In conclusion my sensors are ok , is the promem in last versions of Mycodo. I notice that error after first update in february or march 5.0.16 (2017-03-30) . I dont remember for sure. From that moment daemon still crash once off 2 or 3 days , but after restart everything become to normal others 2 or 3 days. I dont know where is the mistake. I didn't made a new issue because i didn't think is important but i realise , now after so many versions will be more dificult fo find it.

[kizniche]

I don't have an issue with any of my multiple systems of the daemon spontaneously crashing, so I won't be able to directly help in finding the issue, because I cannot replicate it. I can only increase the logging in hopes there is a relevant log line that is produced on your system.

[wangine]

Yea. Thanks for that . I have a free RPi now for tests, i need to receive the two sensors SHT75 and 71 to made the real test. If i pull out the SHT25 or 75 in last version of Mycodo , the daemon will crash after some minutes and some time instantly , In those old versions even the sensors are dead daemon will still running. Example here, the sensor are pulled out and system dont crash. I don't have an issue with any of my multiple systems of the daemon spontaneously crashing, Did you try to install the last version on a fresh Jessie image? You will get error on first try , i try it several times on two differents SD cards and two RPi boards in last two days.Still maybe you have right about "expand file system". I will try in hard way , manualy with fdisk as sudo.

[wangine]

No , i think my partitions are OK. pi@raspberrypi:~ $ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 29766524 4407668 24089080 16% / devtmpfs 435668 0 435668 0% /dev tmpfs 440276 0 440276 0% /dev/shm tmpfs 440276 6108 434168 2% /run tmpfs 5120 8 5112 1% /run/lock tmpfs 440276 0 440276 0% /sys/fs/cgroup /dev/mmcblk0p1 64456 22240 42216 35% /boot tmpfs 88056 0 88056 0% /run/user/1000 and on second one with last version pi@raspberrypi:~ $ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 15473580 2061164 12752460 14% / devtmpfs 468148 0 468148 0% /dev tmpfs 472756 0 472756 0% /dev/shm tmpfs 472756 12236 460520 3% /run tmpfs 5120 8 5112 1% /run/lock tmpfs 472756 0 472756 0% /sys/fs/cgroup /dev/mmcblk0p1 42030 21418 20612 51% /boot Files are expanded