Closed eyespoint closed 5 years ago
Can you provide any details about this pump?
Documentation, python libraries, how it operates, how it can be best integrated into Mycodo, etc.?
Thanks for the interest, I have attached available documentation and python code from Atlas Scientific. Pump is controlled by ASCII strings via I2C. For example I can send D,10 when I run the script and set the I2C address to pump, and it will dispense 10ml. Python libraries and code have been obtained from atlas scientific and tentacle T3. T3 is a Pi hat I am using to connect various I2C devices.
https://www.whiteboxes.ch/docs/tentacle/t3/#/code
EZO_PMP_Datasheet.pdf pi_i2c_sample_code.pdf i2c1.zip
I also have Ph and EC probe and I am trying to integrate in to mycodo. When I run the python script from atlas I get a reading, but I can not get a read to show in mycodo. Not sure how to proceed or get the values to appear in mycodo for Ph and EC as well. I am using EZO circuits from Atlas to connect probes. Ph probe is on I2C address 0x63 EC probe is on I2C address 0x64 EZO-PMP is on the I2C 0x67
I have all equipment and I am available for testing. Please let me know how I can help. Hope we can make this work. Thanks in advance.
Since I've been putting all my effort into the 7.0 release, I haven't been pushing fixes for the current stable version. However, I have already diagnosed the Atlas pH Input issue and the issue has already been resolved in 7.0.
To fix the pH Input, change the following line:
to this:
return dict(ion_concentration=float(self._ph))
Save, then restart the backend from the Config menu.
As for the EC Input, I haven't received any issue reports and have yet to diagnose that issue, though it doesn't seem like it has the same issue as the pH Input.
If you can provide me SSH access (user pi) and a Mycodo UI admin user, I could perform some tests to diagnose and hopefully fix your EC issue. You can contact me privately at http://kylegabriel.com/contact
Also, that Atlas I2C code is already implemented in Mycodo to communicate with Atlas devices, so integrating the pump should be relatively easy. I would just have to figure out how it would be best integrated. When I asked for your opinion of this, I was more asking how you would be using the pump as it relates to Mycodo (i.e. where you would like to see it in the UI, how it could be configured, where it would get its signal from (10 ml), etc.). I am leaning toward it being another type of output, which could be controlled by PIDs or other Functions.
Thanks, I have sent you the login details. After more reading about the EC EZO circuit it was necessary to specify the probe type (K 1.0 in my case) and the EC readings started to show up immediately in mycodo. The only thing that I can't get working is the EZO-PMP from Atlas. I am available for testing when you have the chance. Regarding how the pump will be used how you described it is exactly the use case scenario. It should be in the outputs where it can be controlled by the functions. I am using the pumps to set a certain Ph and EC values by either adding more water up to a certain level to dilute or add chemicals to adjust Ph/EC. The signal on how much to dispense will come from a calculation after I calibration of the tank. More or less I know how much ml/L needs to be added to get the right dose. What I would like to try is to get this to be done automatically via PIDs. It can be done in iterative steps as well. Smallest unit dispensed by the pump is 0.5ml. So I could start adding 0,5ml by 0.5ml and measure in between the additions until desired values are reached. Hope this helps you. Please let me know how I can help with getting the pump working. I am thinking to go route of a script that gets executed as well. What do you think would be the best approach?
I was going to diagnose the EC issue, but since that's resolved, I don't have a need to remotely connect. I'll see about adding the pump as an output in the 7.0 branch and then return to see if you can test it.
The pump should now be working in the 7.0 branch, if you want to install and test it.
I will install today and will let you know how it went
On Thu, Nov 22, 2018, 11:00 Kyle Gabriel <notifications@github.com wrote:
The pump should now be working in the 7.0 branch, if you want to install and test it.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kizniche/Mycodo/issues/562#issuecomment-441071536, or mute the thread https://github.com/notifications/unsubscribe-auth/AqzAbJqB_ikd-zkPYQlWDj7yB7Qb6fzIks5uxsofgaJpZM4YVGiY .
I have installed the 7.0 branch over the 6.4.5 after renaming folder to Mycodo_old1 and I can't seem to find where or how to add the pump in the system. When I open system information this is what I get. Still shows 6.4.5
Mycodo Version: 6.4.5 Python Version: 3.5.3 (default, Sep 27 2018, 17:25:39) [GCC 6.3.0 20170516] Database Version: 15bd5d08a4f0 Daemon Status: Running Daemon Process ID: 5177 Daemon RAM Usage: 46.64 MB Daemon Virtualenv: Yes Frontend RAM Usage: 54.352 MB Frontend Virtualenv: Yes
Did I do the install wrong or something else I am missing?
[image: Mailtrack] https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5& Sender notified by Mailtrack https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5& 11/22/18, 10:27:35 PM
On Thu, Nov 22, 2018 at 12:11 PM Milos Lazic it.milos@gmail.com wrote:
I will install today and will let you know how it went
On Thu, Nov 22, 2018, 11:00 Kyle Gabriel <notifications@github.com wrote:
The pump should now be working in the 7.0 branch, if you want to install and test it.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kizniche/Mycodo/issues/562#issuecomment-441071536, or mute the thread https://github.com/notifications/unsubscribe-auth/AqzAbJqB_ikd-zkPYQlWDj7yB7Qb6fzIks5uxsofgaJpZM4YVGiY .
-- Srdačan pozdrav,
Miloš Lazić Mob: +1 513 334 7840 Skype: milos_lazic
This is how I would install the 7.0 branch if you already have a previous version running:
sudo service mycodo stop
sudo service mycodoflask stop
sudo mv ~/Mycodo ~/Mycodo-backup
cd
git clone github.com/kizniche/Mycodo
cd ~/Mycodo
git checkout major_release_v7.0
sudo /bin/bash ~/Mycodo/install/setup.sh
Thanks a lot for the info. That worked well. Did the install, now it shows as ver. 7.0 and i can see the ezo-pmp in outputs and set it up. However it does not work properly yet. I do not have option to activate the output and I'm not sure about 10ml/min setting. The pump has several modes of operation it can be set to, like constant dispensing mode. I believe that is what you were refering to with the 10ml/min setting. In my case I do not want it to constantly dispense but conditionaly on ph and ec values. Also I will be using 3 pumps via I2C to dispense different liquids. The button where I can put the ml value and dispense the volume on the bottom of settings does not work properly. Pump starts and stops immediately and disregards the value. Also, field for value should accept the - value (example -6) that would run the pump in opposite direction. At the moment if i enter negative value the system throws an error. Pump can also be calibrated etc... Remote login is still valid if you need to dial in. Let me know what I can try to troubleshoot further.
On Thu, Nov 22, 2018, 22:31 Kyle Gabriel <notifications@github.com wrote:
This is how I would install the 7.0 branch if you already have a previous version running:
sudo service mycodo stop sudo service mycodoflask stop sudo mv ~/Mycodo ~/Mycodo-backup cd git clone github.com/kizniche/Mycodo cd ~/Mycodo git checkout major_release_v7.0 sudo /bin/bash ~/Mycodo/install/setup.sh
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kizniche/Mycodo/issues/562#issuecomment-441150035, or mute the thread https://github.com/notifications/unsubscribe-auth/AqzAbCeTjvTfQE_3VIpUJtXdHA9d8Toaks5ux2wPgaJpZM4YVGiY .
The current code will calculate how long it needs to run to dispense a particular volume of fluid based on the set flow rate (ml/min). You can review the calculation in the following lines of the output controller:
The command uses the Dose over time ("D,[ml],[min]", p. 57 of datasheet), however since I don't have the pump, I cannot test whether a decimal can be used instead of a integer (for dispensing for less than 1 minute). This is where I need you to attempt to dispense an amount (expand the output with the plus icon, then enter an amount in the "Amount to Dispense" box, then select "Pump Volume". Now, go to the log page (Config -> Mycodo Logs) and select Daemon, then copy any errors you see.
If the Dose over time cannot accept a decimal input, then I will have to modify the code to only use Volume dispensing ("D,[ml]", p. 56 of the datasheet).
At the moment, I cannot remotely log in, but I can review the errors you find and try to fix the code. I may be able to remote connect later today or tomorrow.
Hi Kyle,
I have been doing extensive testing with the EZO-PMP on 7.0 and this is what I have seen. Dose over time can accept decimal input and if I run the sample code from atlas scientific and sent D,50,1 it will dispense a 50ml in 1min. This is maximum amount that can be dispensed in dose over time mode in 1min. Pump works in short impulses and dispenses. I was able to go down to D,3,0.06 by halfing the time and amount from the max 50ml/min. However, I can not reproduce this behavior through mycodo no matter what combo I put in the fields. Can I suggest to implement all 3 modes of dispensing so it can be chosen between them. Please see below the daemon log. Let me know what else could I try to help. Thanks.
Last 30 lines of /var/log/mycodo/mycodo.log:
2018-11-25 23:04:47,588 - mycodo.daemon - INFO - 39.32 MB RAM in use 2018-11-27 19:34:52,455 - mycodo.daemon - INFO - Mycodo daemon v7.0.0 starting 2018-11-27 19:34:53,443 - mycodo.daemon - INFO - Anonymous statistics enabled 2018-11-27 19:34:53,468 - mycodo.daemon - INFO - Starting rpyc server 2018-11-27 19:34:53,947 - mycodo.output - INFO - Output controller activated in 158.1 ms 2018-11-27 19:34:54,448 - mycodo.daemon - INFO - All activated Conditional controllers started 2018-11-27 19:34:54,449 - mycodo.daemon - INFO - All activated Trigger controllers started 2018-11-27 19:34:54,997 - mycodo.input_78752554 - INFO - Activated in 309.7 ms 2018-11-27 19:34:55,788 - mycodo.input_bbbd7c5b - INFO - Activated in 296.0 ms 2018-11-27 19:34:55,789 - mycodo.daemon - INFO - All activated Input controllers started 2018-11-27 19:34:55,789 - mycodo.daemon - INFO - All activated Math controllers started 2018-11-27 19:34:55,790 - mycodo.daemon - INFO - All activated PID controllers started 2018-11-27 19:34:55,790 - mycodo.daemon - INFO - All activated LCD controllers started 2018-11-27 19:34:56,291 - mycodo.daemon - INFO - Mycodo daemon started in 3.819 seconds 2018-11-27 19:34:56,302 - mycodo.daemon - INFO - 39.41 MB RAM in use 2018-11-27 20:23:31,179 - mycodo.daemon - INFO - Mycodo daemon v7.0.0 starting 2018-11-27 20:23:32,342 - mycodo.daemon - INFO - Anonymous statistics enabled 2018-11-27 20:23:32,371 - mycodo.daemon - INFO - Starting rpyc server 2018-11-27 20:23:32,825 - mycodo.output - INFO - Output controller activated in 125.5 ms 2018-11-27 20:23:33,326 - mycodo.daemon - INFO - All activated Conditional controllers started 2018-11-27 20:23:33,327 - mycodo.daemon - INFO - All activated Trigger controllers started 2018-11-27 20:23:33,886 - mycodo.input_78752554 - INFO - Activated in 428.9 ms 2018-11-27 20:23:34,506 - mycodo.input_bbbd7c5b - INFO - Activated in 275.8 ms 2018-11-27 20:23:34,507 - mycodo.daemon - INFO - All activated Input controllers started 2018-11-27 20:23:34,508 - mycodo.daemon - INFO - All activated Math controllers started 2018-11-27 20:23:34,508 - mycodo.daemon - INFO - All activated PID controllers started 2018-11-27 20:23:34,509 - mycodo.daemon - INFO - All activated LCD controllers started 2018-11-27 20:23:35,010 - mycodo.daemon - INFO - Mycodo daemon started in 3.821 seconds 2018-11-27 20:23:35,026 - mycodo.daemon - INFO - 39.33 MB RAM in use 2018-11-27 21:58:29,837 - mycodo.output - ERROR - EZP-PMP volume value must be greater than 0
[image: Mailtrack] https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5& Sender notified by Mailtrack https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5& 11/28/18, 11:57:22 AM ×REMOVE <#m6307116644828841763>
On Fri, Nov 23, 2018 at 10:44 AM Kyle Gabriel notifications@github.com wrote:
At the moment, I cannot remotely log in, but I can review the errors you find and try to fix the code. I may be able to remote connect later today or tomorrow.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kizniche/Mycodo/issues/562#issuecomment-441271855, or mute the thread https://github.com/notifications/unsubscribe-auth/AqzAbALILVAtdLhRMppX85MGZk7ql0GZks5uyBfTgaJpZM4YVGiY .
-- Srdačan pozdrav,
Miloš Lazić Mob: +1 513 334 7840 Skype: milos_lazic
I tried to connect to your system a few days ago but it said it was offline. I planned to implement the rate-set and rate-unset methods for dispensing, though I need to get at least one method working before I attempt to add another.
One issue I'll have when connecting remotely is I won't know if the pump is actually dispensing unless you set up a camera and have two vessels I can move fluid back and forth (preferably colored liquid).
I just updated the EZO-PMP code to be more sane and to include debugging lines that will show up in the Daemon long whenever the pump is supposed to be actuated so we can see the exact commands being given to it. If you are updating your code with cd ~/Mycodo && git fetch && git pull
you will most likely need to delete your database because there have been schema changes that will cause errors. You can fix this by recreating your database with sudo rm -rf ~/Mycodo/databases/mycodo.db && sudo service mycodoflask restart
then load the web page to create a new admin user. After doing that (must refresh the web page to generate the new database), then restart the daemon with sudo service mycodo restart
and you can then add the pump as an output and test.
Thanks Kyle,
I have tried to do as you instructed but I got a torrent of error along the way. I will try to be as detailed as possible to help you troubershoot with me. Here we go. I get an error below when I run the first command to fetch and pull
error: cannot open .git/FETCH_HEAD: Permission denied
To resolve it i went chmod 777 on all of Mycodo folder recursively
Tried again and got an error below on the pull
Please commit your changes or stash them before you merge
This was resolved by command
git reset -- hard
Fetch and pull got the new files after this without any errors. After that I ran the second command to delete and recreate the db. I got the following msg
Warning: mycodoflask.service changed on disk Run 'systemctl daemon- reload' to reload units
I run the 'systemctl daemon- reload' but a raspbian gui comes prompting for pi user password. I punched it in but the command timed out.
This was resolved by reboot of raspberry pi. After restart i ran the command again and it was a success. I logged in and created new user and logged in to web gui.
I ran the third command to restart mycodo service and was greeted by below error
Job for mycodo.service failed because the control process exited with error code . See "systemctl status mycodo.service" and "journalctl _xe" for details
When I run the "systemctl status mycodo.service" I get the output below
pi@Aquarium1:~ $ systemctl status mycodo.service ● mycodo.service - Mycodo server Loaded: loaded (/home/pi/Mycodo/install/mycodo.service; enabled; vendor prese Active: failed (Result: exit-code) since Fri 2018-11-30 15:24:05 MST; 4min 4s Process: 3012 ExecStart=/var/mycodo-root/env/bin/python /var/mycodo-root/mycod
Nov 30 15:24:05 Aquarium1 python[3012]: File "/var/mycodo-root/mycodo/mycodo_d Nov 30 15:24:05 Aquarium1 python[3012]: from mycodo.controller_conditional i Nov 30 15:24:05 Aquarium1 python[3012]: File "/var/mycodo-root/mycodo/controll Nov 30 15:24:05 Aquarium1 python[3012]: exec each_module Nov 30 15:24:05 Aquarium1 python[3012]: ^ Nov 30 15:24:05 Aquarium1 python[3012]: SyntaxError: Missing parentheses in call Nov 30 15:24:05 Aquarium1 systemd[1]: mycodo.service: Control process exited, co Nov 30 15:24:05 Aquarium1 systemd[1]: Failed to start Mycodo server. Nov 30 15:24:05 Aquarium1 systemd[1]: mycodo.service: Unit entered failed state. Nov 30 15:24:05 Aquarium1 systemd[1]: mycodo.service: Failed with result 'exit-c lines 1-15/15 (END)...skipping... ● mycodo.service - Mycodo server Loaded: loaded (/home/pi/Mycodo/install/mycodo.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2018-11-30 15:24:05 MST; 4min 4s ago Process: 3012 ExecStart=/var/mycodo-root/env/bin/python /var/mycodo-root/mycodo/mycodo_daemon.py (code=exited, status=1/FAILURE)
Nov 30 15:24:05 Aquarium1 python[3012]: File
"/var/mycodo-root/mycodo/mycodo_daemon.py", line 52, in
and after I run the "journalctl _xe" I get the output below
pi@Aquarium1:~ $ journalctl -xe Nov 30 15:24:05 Aquarium1 python[3012]: File "/var/mycodo-root/mycodo/controller_conditional.py", line 280 Nov 30 15:24:05 Aquarium1 python[3012]: exec each_module Nov 30 15:24:05 Aquarium1 python[3012]: ^ Nov 30 15:24:05 Aquarium1 python[3012]: SyntaxError: Missing parentheses in call to 'exec' Nov 30 15:24:05 Aquarium1 systemd[1]: mycodo.service: Control process exited, code=exited status=1 Nov 30 15:24:05 Aquarium1 systemd[1]: Failed to start Mycodo server. -- Subject: Unit mycodo.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit mycodo.service has failed. -- -- The result is failed. Nov 30 15:24:05 Aquarium1 systemd[1]: mycodo.service: Unit entered failed state. Nov 30 15:24:05 Aquarium1 systemd[1]: mycodo.service: Failed with result 'exit-code'. Nov 30 15:24:05 Aquarium1 sudo[3003]: pam_unix(sudo:session): session closed for user root Nov 30 15:25:54 Aquarium1 influxd[306]: ts=2018-11-30T22:25:54.457611Z lvl=info msg="Cache snapshot (start)" log_id=0C5fupfW000 engine=tsm1 trace_id=0C5gVN6G0 Nov 30 15:25:54 Aquarium1 influxd[306]: ts=2018-11-30T22:25:54.821830Z lvl=info msg="Snapshot for path written" log_id=0C5fupfW000 engine=tsm1 trace_id=0C5gVN Nov 30 15:25:54 Aquarium1 influxd[306]: ts=2018-11-30T22:25:54.822057Z lvl=info msg="Cache snapshot (end)" log_id=0C5fupfW000 engine=tsm1 trace_id=0C5gVN6G000 Nov 30 15:26:01 Aquarium1 influxd[306]: ts=2018-11-30T22:26:01.457479Z lvl=info msg="Cache snapshot (start)" log_id=0C5fupfW000 engine=tsm1 trace_id=0C5gVnSG0 Nov 30 15:26:01 Aquarium1 influxd[306]: ts=2018-11-30T22:26:01.720284Z lvl=info msg="Snapshot for path written" log_id=0C5fupfW000 engine=tsm1 trace_id=0C5gVn Nov 30 15:26:01 Aquarium1 influxd[306]: ts=2018-11-30T22:26:01.721907Z lvl=info msg="Cache snapshot (end)" log_id=0C5fupfW000 engine=tsm1 trace_id=0C5gVnSG000 Nov 30 15:31:11 Aquarium1 systemd[1]: Starting Cleanup of Temporary Directories... -- Subject: Unit systemd-tmpfiles-clean.service has begun start-up -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit systemd-tmpfiles-clean.service has begun starting up. Nov 30 15:31:11 Aquarium1 systemd[1]: Started Cleanup of Temporary Directories. -- Subject: Unit systemd-tmpfiles-clean.service has finished start-up -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit systemd-tmpfiles-clean.service has finished starting up. -- -- The start-up result is done. Nov 30 15:33:05 Aquarium1 vncserver-x11[402]: Connections: connected: 192.168.0.15::51672 Nov 30 15:33:05 Aquarium1 vncserver-x11[402]: session started: user pi permissions f Nov 30 15:33:05 Aquarium1 vncserver-x11[402]: Connections: authenticated: 192.168.0.15::51672, as pi (f permissions) Nov 30 15:33:05 Aquarium1 vncserver-x11[402]: SPrintConnMgr: Failed to add printer: server-error-service-unavailable lines 2053-2092/2092 (END)
At this point I decided to restart the raspberry pi one more time in hope mycodo service would start. After restart the error persists. I am stuck at this moment being unable to create ezo-pmp output. when I try from web interface mycodo throws below error
×
From what I see it all points to the file below file missing some parentheses in call to exec I'm not python expert so not sure how to troubleshoot from here. Please help!
File "/var/mycodo-root/mycodo/controller_conditional.py", line 280 Nov 30 15:41:34 Aquarium1 python[1748]: exec each_module Nov 30 15:41:34 Aquarium1 python[1748]: ^ Nov 30 15:41:34 Aquarium1 python[1748]: SyntaxError: Missing parentheses in call to 'exec
On Fri, Nov 30, 2018, 14:24 Kyle Gabriel <notifications@github.com wrote:
I just updated the EZO-PMP code to be more sane and to include debugging lines that will show up in the Daemon long whenever the pump is supposed to be actuated so we can see the exact commands being given to it. If you are updating your code with cd ~/Mycodo && git fetch && git pull you will most likely need to delete your database because there have been schema changes that will cause errors. You can fix this by recreating your database with sudo rm -rf ~/Mycodo/databases/mycodo.db && sudo servie mycodoflask restart then load the web page to create a new admin user. After doing that (must refresh the web page to generate the new database), then restart the daemon with sudo service mycodo restart and you can then add the pump as an output and test.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kizniche/Mycodo/issues/562#issuecomment-443311779, or mute the thread https://github.com/notifications/unsubscribe-auth/AqzAbK1G2IXbKjaKSxp2tvQXnTeH1-Ooks5u0YX5gaJpZM4YVGiY .
[image: Mailtrack] https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5& Sender notified by Mailtrack https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5& 11/30/18, 5:50:52 PM
Try these commands:
sudo service mycodo stop
sudo /bin/bash ~/Mycodo/mycodo/scripts/upgrade_commands.sh initialize
sudo service mycodo start
I have tried and the result is the same error when I try to start the service. Should I just try to install fresh copy and what would be the best way to go about it?
[image: Mailtrack] https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5& Sender notified by Mailtrack https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5& 11/30/18, 6:33:02 PM
On Fri, Nov 30, 2018 at 6:23 PM Kyle Gabriel notifications@github.com wrote:
Try these commands:
sudo service mycodo stop sudo /bin/bash ~/Mycodo/mycodo/scripts/upgrade_commands.sh initialize sudo service mycodo start
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kizniche/Mycodo/issues/562#issuecomment-443369872, or mute the thread https://github.com/notifications/unsubscribe-auth/AqzAbDQvDiS3mBiCjNxkAsl7feX7S86fks5u0b3ogaJpZM4YVGiY .
-- Srdačan pozdrav,
Miloš Lazić Mob: +1 513 334 7840 Skype: milos_lazic
Try this:
sudo /bin/bash ~/Mycodo/install/setup.sh
still the same. No change. I have even deleted the Mycodo folder and run the install from scratch with
sudo service mycodo stop sudo service mycodoflask stop sudo mv ~/Mycodo ~/Mycodo-backup cd git clone https://www.github.com/kizniche/Mycodo cd ~/Mycodo git checkout major_release_v7.0 sudo /bin/bash ~/Mycodo/install/setup.sh
after a new install I still have the same issue. Any ides what else can I try to make it work?
Daemon refused to start with the same error no matter what. So I googled around and found this article
it shows that parentheses were needed in python 3.0 versus 2.7. I edited the file controller_conditional.py, line 280 from exec each_module to exec (each_module)
that made daemon start again and now I can activate inputs and get reading on Ph and EC. I still get an error when I try to add EZO-PMP in web gui image
I tried to add other type of output as well with same result. This is from daemon log.
2018-11-30 18:52:03,615 - mycodo.daemon - INFO - Mycodo daemon v7.0.0 starting 2018-11-30 18:52:03,968 - mycodo.daemon - INFO - Anonymous statistics enabled 2018-11-30 18:52:03,992 - mycodo.daemon - INFO - Starting rpyc server 2018-11-30 18:52:04,329 - mycodo.output - INFO - Output controller activated in 100.3 ms 2018-11-30 18:52:04,830 - mycodo.daemon - INFO - All activated Conditional controllers started 2018-11-30 18:52:04,832 - mycodo.daemon - INFO - All activated Trigger controllers started 2018-11-30 18:52:05,305 - mycodo.input_fbb67378 - INFO - Activated in 363.5 ms 2018-11-30 18:52:05,591 - mycodo.input_dc4cff8f - INFO - Activated in 203.5 ms 2018-11-30 18:52:05,592 - mycodo.daemon - INFO - All activated Input controllers started 2018-11-30 18:52:05,593 - mycodo.daemon - INFO - All activated Math controllers started 2018-11-30 18:52:05,593 - mycodo.daemon - INFO - All activated PID controllers started 2018-11-30 18:52:05,593 - mycodo.daemon - INFO - All activated LCD controllers started 2018-11-30 18:52:06,094 - mycodo.daemon - INFO - Mycodo daemon started in 2.478 seconds 2018-11-30 18:52:06,097 - mycodo.daemon - INFO - 39.45 MB RAM in use 2018-11-30 18:52:18,033 - mycodo.output - ERROR - 1 Traceback (most recent call last): File "/var/mycodo-root/mycodo/controller_output.py", line 826, in add_mod_output self.output_type[output_id] = output.output_type AttributeError: 'Query' object has no attribute 'output_type' 2018-11-30 18:52:27,304 - mycodo.output - ERROR - 1 Traceback (most recent call last): File "/var/mycodo-root/mycodo/controller_output.py", line 826, in add_mod_output self.output_type[output_id] = output.output_type AttributeError: 'Query' object has no attribute 'output_type' 2018-11-30 18:52:34,679 - mycodo.output - ERROR - 1 Traceback (most recent call last): File "/var/mycodo-root/mycodo/controller_output.py", line 826, in add_mod_output self.output_type[output_id] = output.output_type AttributeError: 'Query' object has no attribute 'output_type'
Any steps you can recommend to try?
I have troubleshooted your remote access issue. You should be able to log in remotely now. Le me know if you have any problems connecting.
Have you tried rebooting after the initializations/installs? It's always good to just reboot to see if a fresh boot brings services up properly.
Try also disabling the input, change the data pin to another BCM pin, change the setting on the input in the web UI, save, then reactivate the input.
I will see about connecting my DHT22 later today to see if I have an issue acquiring measurements.
Hi Kyle,
I have tried many things including reboots. This is what it had boiled down to.
https://github.com/kizniche/Mycodo/issues/562#issuecomment-443389606
Please let me know if you have any suggestions on how to continue. daemon was not starting due to python version parenthesis missing issue. On the link above you can se onn github I left a comment for the issue.
This is what Daemon is pointing to now, I am unable to add any output becaouse it is not an "output_type". Not sure what that means exactly. I'm no expert by any measure but I will try to check the code in controller_output.py on line below and compare to one from previous commit that worked to try and spot the issue. Your help would be greatly appreciated.
Traceback (most recent call last): File "/var/mycodo-root/mycodo/controller_output.py", line 826, in add_mod_output self.output_type[output_id] = output.output_type AttributeError: 'Query' object has no attribute 'output_type'
Try also disabling the input, change the data pin to another BCM pin, change the setting on the input in the web UI, save, then reactivate the input.
One question, how can I change I2C to another PIN? I use atlas circuits +T3 on I2C. I was not aware I can change I2C pins on Pi to other. Please advise.
It appears I've bene replying to the wrong issue. My mistake.
it shows that parentheses were needed in python 3.0 versus 2.7. I edited the file controller_conditional.py
You are correct, I did not test this when I implemented it. I'll change it.
Sorry for the confusion.
AttributeError: 'Query' object has no attribute 'output_type'
I believe the database schema has been updated and you're using an old database. Please follow these instructions to build a new database and test:
sudo service mycodo stop
sudo rm -rf ~/Mycodo/databases/mycodo.db
sudo service mycodoflask restart
Reload the webpage and you should see the "create Admin User" page.
sudo service mycodo start
Create an admin user, add the pump as an output, and try to test.
Ok, I will try that now and let you know. Feel free to join me remotely, should be ok.
On Sat, Dec 1, 2018, 16:42 Kyle Gabriel <notifications@github.com wrote:
AttributeError: 'Query' object has no attribute 'output_type'
I believe the database schema has been updated and you're using an old database. Please follow these instructions to build a new database and test:
sudo service mycodo stop sudo rm -rf ~/Mycodo/databases/mycodo.db sudo service mycodoflask restart
Reload the webpage and you should see the "create Admin User" page.
sudo service mycodo start
Create an admin user, add the pump as an output, and try to test.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kizniche/Mycodo/issues/562#issuecomment-443460733, or mute the thread https://github.com/notifications/unsubscribe-auth/AqzAbFl6_7G6I0kTpJXJK3G1tRr6AF_1ks5u0ve0gaJpZM4YVGiY .
Actually, I'm now not quite sure why you're getting the error that output_type isn't in the schema. In any case, I've progressed a bit more with the VNC to connect to your system, but I'm now at a new login screen. I've emailed you the details.
Have you had a chance to test the new code after the fix I pushed 4 days ago?
I currently don't have this piece yet -was running the add on to see how it work - will follow up if I end up getting it. these are a bit expensive/limited. Working on setting up other pump set up and will share what I find out
Okay, thanks.
Hi Kyle, I'm back at my project and have set up the EZO-PMP from Atlas again. I believe the issue is in the code referenced below, and how it calculates the command. I am available for testing and would like to sort this out. Let me know when you have the time to test. In short this is the issue I was able to pinpoint.
https://github.com/kizniche/Mycodo/blob/master/mycodo/controllers/controller_output.py
In the lines of code below you are calculating the rate of flow to be dispensed. What is desired, is the ability to calibrate and give desired quantity only without time limit, but as fast as possible to dispense the desired volume. Basically, Mycodo should execute D,10 and nothing else. The way it is set up if I enter 10ml to dispense in output Daemon logs the following command. So it multiplies it by trigger 10 and it comes to D,10.00,100 and dispenses 10ml over 100min. Even when trigger field is adjusted to 1 it will generate D,10.00, 10 *10ml over 10min) This is too slow when you need to inject a certain volume and do it as fast as possible.
2019-09-09 17:07:44,640 - ERROR - mycodo.controllers.controller_output - EZO-PMP command: D,10.00,100.00
Code snipet that generates this is below:
if self.output_type[output_id] == 'atlas_ezo_pmp':
**volume_ml = duration**
if state == 'on' and volume_ml > 0:
# Calculate command, given flow rate
**minutes_to_run = self.output_flow_rate[output_id] * volume_ml**
**write_cmd = 'D,{ml:.2f},{min:.2f}'.format(
ml=volume_ml, min=minutes_to_run)
self.logger.error("EZO-PMP command: {}".format(write_cmd))**
self.atlas_command[output_id].write(write_cmd)
write_db = threading.Thread(
target=write_influxdb_value,
args=(self.output_unique_id[output_id],
'ml',
volume_ml,),
kwargs={'measure': 'volume',
'channel': 0})
write_db.start()
elif state == 'off' or volume_ml == 0:
write_cmd = 'X'
self.logger.error("EZO-PMP command: {}".format(write_cmd))
self.atlas_command[output_id].write(write_cmd)
else:
self.logger.error(
"Invalid parameters: ID: {id}, "
"State: {state}, "
"volume: {vol}".format(
id=output_id, state=state, vol=volume_ml))
I hope I have managed to explain the desired behavior vs the way it is working now by extending the time. Please let me know when you have time so we can troubleshoot this. I'm on the latest version below.
Mycodo Version: 7.7.1 Python Version: 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.2.0] Database Version: 65271370a3a9 Daemon Status: Running Daemon Process ID: 988 Daemon RAM Usage: 48.444 MB Daemon Virtualenv: Yes Frontend RAM Usage: 52.54 MB Frontend Virtualenv: Yes
The "Flow Rate" option was accidentally labeled as "Trigger at Startup" for the EZO Pump on the Outputs page. I corrected this, so there shouldn't be any confusion about the options. I think having the ability to set the flow rate covers more case uses than having a static flow rate. This is why it's currently an option. In the future, I think it would be good to have the option to use a flow rate or just have it pump as fast as it can. Currently, you should be able to set the flow rate the the fastest and achieve the same effect.
You can upgrade to master to get the latest code with the correct label.
I see the error in my minutes_to_run calculation should be "volume_ml / self.output_flow_rate[output_id]" rather than "self.output_flow_rate[output_id] * volume_ml". This equation yields the correct minutes to run now.
Examples:
I refactored the Output measurement system to operate as the Input/Math controllers do, with the ability to store multiple measurements per device (until now only one measurement per Output was feasible). Now I am able to add the amount of time that the pump runs for (in minutes) as a stored measurement. This way you can know how long the pump ran for the volume of fluid dispensed. This may also help with Conditional programming if you needed to incorporate the flow rate into your conditional statement.
This code hasn't been released yet, but can be obtained by upgrading to master. Keep in mind that this was a pretty big change and I may still be making fixes to issues I find, until it's stable enough for release. What that means is if you upgrade to master, it may mess up your install from being able to happily upgrade to the next official release, and you may have to delete your database to generate a new one that has the correct schema. If you do decide to try the pre-release, after the upgrade to master, you will have to delete any current EZO Pump Outputs and add them again for this new measurement to appear.
More fixes being committed. Now Output measurements can be used in measurement widgets.
I think I finally have all parts of the Dashboard working with the new Output measurement system.
If you want to see the commands being sent to the pump, you'll also need to check the Enable Daemon Debug Logging option in the General Settings on the Configuration page, then restart the daemon.
Hi Kyle,
I have tested the update before last, and this is what I have found. The math now works as you stated. The max flow rate of the pump is 105ml/min according to documentation, and the math from photo below generates the below in the Daemon log
2019-09-13 19:37:25,130 - ERROR - mycodo.controllers.controller_output - EZO-PMP command: D,17.50,0.17
What I have tried, as you suggested, is use the pumps max flow rate of 105ml/min to dispense 17.5ml of liquid. The command generated by the math *D,17.50,0.17)and it does not turn on pump at all. It should in theory, run the motor for 10.2s at max flow rate, and dispense the exact amount. Thought it was most likely a formatting issue, with the dots and the comas in the command generated and whatnot and checked in Atlas scientific sample code. It generated Error 2 when I enter the command. I have played around with numbers and have observed that pump works differently in this mode, eg. it works in short pulses vs one continuous run, and the effective max flow rate is limited to 50ml/min. (please see below for rate) issues with error 2 has to do with overstepping 50ml/min flow limit, thus creating the Error 2.
While I understand your argument about broader use case, maybe we should take a step back and add one mode of the pump at the time. Dispensing certain volume and calibration feature in Mycodo would be awesome and highly appreciated. Im here to test anything you need. This pump is mostly useful to dose exact small amounts of liquid in 0.5ml granularity accurately after calibration.
This is the limit of the pump flow rate of 25ml in 30sec in this mode.
I read the flow rate is limited by the calibration. Perhaps you need to calibrate your pump before it will work properly in the flow rate mode. In any case, I will work on adding an option in the output settings to select either "Fastest Dispense" or "Select Flow Rate".
Perhaps it's a decimal issue (probably not). Try rounding the float value to "0.1" or "0.2", rather than "0.17".
Mycodo Issue Report:
Specific Mycodo Version:
6.4.5
Problem Description
Please list
Errors
Steps to Reproduce the issue:
How can this issue be reproduced?
Additional Notes
Is there anything that should be added to make it easier to address this issue?