kizniche / mycodo Goto Github PK

The min duration is supposed to limit the relay minimum on duration. If the PID output is below this value, the relay is suppose not turn on at all. The current operation is if the PID value is positive and below the minimum duration, the relay will turn on for the minimum duration.

Hello again!

I have a question about one of the most used variables in mycodo.py. sensor is used all over the place and I believe it is an int and the address of a sensor. But I am not sure.

I see that when it is used in logging it tends to have 1 added to it. This makes me think that internally the sensors are numbered 0-7 but in the log you refer to them as 1-8.

Could you clarify what this variable is used for in mycodo.py?

Out of curiosity why is time cast as an int in your code?

Examples:

roughly L2009 in mycodo.py

while last_ht_reading > int(time.time()):
        time.sleep(0.25)

or

roughly L2038 in mycodo.py

last_ht_reading = int(time.time()) + 2

time.time() returns a float normally and python will add and compare ints and floats without issue.

It produce inexact results in timers as well.

Consider time.time() is 1448345968.99. Converted to an int that is 1448345968. It takes one time.sleep(0.25) to become 1448345969.

Now consider time.time() is 1448345968.01. Again converted to an int that is 1448345968. But it takes 4 time.sleep(0.25) to become 1448345969.

Your readings from the sensors could take ± .75 seconds here. Floats would alleviate the precision issue.

Just curious. :)

when either of thoses 2 buttons are clicked the result is a white page

Thumbnails in the notes section currently are not true "thumbnails" but merely scaled versions of the full-resolution image. Since this can be a big bandwidth hog, the option to show note thumbnails should be included in the settings.

Trying to update Mycodo from v3.5.89 to current (to add the fix for timers and triggers). The daemon shuts down fine and the update finishes without issue (at least according to logs). But the daemon will not start back up... not from the web interface (which shows up with the daemon off and the last log entry is the update switching off the daemon) and not from the command line (via "sudo service mycodo start"). I tried restarting the Pi as well, but the daemon will not start back up. I've tried a few times now and the same thing happens every time.

(I meant to say before that this software is great. Thank you so much for making and maintaining it, and also for your fast responses.)

Currently, logs can fill the 30MB tempfs /var/tmp/ between the 6-hour scheduled backups, especially if the daemon is running in debug mode (verbose logging).

@boomstick8x I'm starting this (and deleting the other posts) because it was off-topic for that thread (and there's a lot of chat, so I don't want who is subscribed to that issue to keep getting notified).

Is there an error of any kind?

Turn ON or OFF public/anonymous direct access to the graph/tab page : perhaps a special graph page with a link to, from the login/index.php page.
Turn ON or OFF password showing for user guest in the main login page : index.php
Turn ON or OFF password need for user guest in the main login page : index.php

When analysing my graph with the DATA tab, I realise that "combined" won't show the relays run time on the graph

Can trigger relay or email notification, for instance.

Currently only one can be selected from the Pycodo user group, however the Python email function being used permits sending to multiple recipients.

There is already a "maximum on time" (titled Up Max and Down Max, for each relay of the PID), that the on time for a relay will not exceed. There needs to be a complementary minimum on time that if the PID does not exceed, the relay does not turn on.

This is an effort to reduce the bloat of mycodo.py and allow fewer requirements for its use, based on what is being used by it (modules). I can foresee, with many supported sensors/devices, Mycodo getting unmanageable and requiring the installation of extraneous software that will never be utilized by some users.

For instance, functions related to reading the AM2315 temperature/humidity sensor would all be in AM2315.py and the TCA9548A multiplexer in TCA9548A.py. They would only be loaded if that sensor/device is in use. That way software will not need to be installed if the device is not used, such as symbus- only used by the TCA9548A.

I'm struggling to find the best way to do this. Often, when I take on big tasks such as rewriting my code for better operability/modularity/readability, my first choice of a method is not necessarily the best course (but seldom is it the worst choice).

To get commit 572dfeb working, I had to temporarily make custom graph generation only work for the past 6 months. It should be an easy fix once I look at that part of the code, but for now everything else works from this major overhaul of the custom graph generation.

Essentially, the custom graph generation was handled in PHP. It is now handled by the Python function that generates the preset graphs on the Graph Tab.

Relay and temperature blocks in sensor tab in case of css .sensor-parent{float: left and width: auto} are different width, and if I`m not wrong, removing float will solve this situation.
And if it so, then in css table.relays{display: table; margin-right: auto; margin-left: auto; width: 100%;} will solve the last part of positioning.

I have a small TFT screen, connected to the Pi
the objectif is to be able to see mycodo/gaphs and at same time you can look throuh the glass inside the fruting chamber.

this base screeen no tactlie , just cheap TFT is only 7''
and the webpage won't fit ! I tryed to reduce the wepage size in chromium with CTRL + +
but all became too small/tight
Ideal, I think, would be to have some graph from terminal directly
I'm sure this is easy to read the sensors log file in real time to show a graph in a terminal window

After yesterday update:
{
Database version 11, v3.5.76
v3.5.76: Add minimum relay on duration for PID controllers
}
my HT-HUM PID is broken. The P and I constants were deleted, and no new values is saved, either.
I don't see any obvious in the code though.

Monitoring is key to any good regulatory system, with redundancy often used to accomplish this. This may be useful for remote operation or where great liability is involved (e.g. keeping things alive, preventing damage of expensive materials, ensuring safety, etc.).

The main use of networking would be to add the ability to monitor the status of a running Mycodo daemon on another device and to respond if there is an issue (e.g. daemon crash, linux kernel panic, corrupt filesystem causing instability, disconnect from the network, loss of regulation, etc.).

Initial features would be the ability to notify by email, power cycle the affected Pi with the use of a normally-closed (NC) relay, or take control of the regulation relays to recover the system from a loss of regulation. Additionally, If the host (monitoring system) experiences an issue, the slave (monitored system) could power-cycle the host.

A point-to-point connection would provide the best security, such as a single ethernet cable (TCP/IP) or serial (Tx/Rx). With a dedicated connection, there are fewer additional points of failure (such as routers, switches, and wireless APs, although these could still be used).

If successful, this feature could potentially lead to more advanced features such as improving graph generation performance or other processes by splitting processing tasks (cluster).

Hello!

I am just curious about the code here:

on my system it seems to produce an array of zeroes. Something like this:

where
conditional_t_number_conditional has a length of 10 and
conditional_t_number_sensor has a length of 4

[[[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]],
 [[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]],
 [[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]],
 [[0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]]]

Could you help me understand this code?

Update the relay on duration logging format to remove the current 8-relay limitation. Although the software supports an infinite number of relays, any over 8 will break the system in unforeseen ways.

Current logging format:
Year Mo Day Hour Min Sec R1SecOn R2SecOn R3SecOn R4SecOn R5SecOn R6SecOn R7SecOn R8SecOn Sensor
2015 09 07 07 15 29 0 -144.25 0 0 0 0 0 0 0

The negative relay duration in the example is valid, as this is derived from a negative PID output, and all numbers are eventually converted to their absolute value. This format was used to distinguish that this relay was used to decrease an environmental condition (rather than increase it). Furthermore, the most recent Mycodo update, which allows for the user to select any number of relays to be graphed, either positive or negative, renders this format unnecessary.

Proposed new logging format:
Year Mo Day Hour Min Sec GPIO-Pin SecOn

enable bright PI light functionality with camera.

https://www.pi-supply.com/bright-pi-v1-0-code-examples/

Wouldn't it be awesome to be abble to write some notes anytime to keep log of anything :

• Grow journal
• PID settings/tuning
• personal notes and comments
  Very important to have automatic time stamps affected when writing the notes/

Few times I run with my eyes more than usually to find Mycodo tab in browser. I can try to make favicon for the project. May be you have an ideas about graphics?

p.s. What Mycodo means? I think first part 'Myco' shortcut from mycology, but the last 'do' I don't understand?

test image:

Groups currently only include guest and admin.
Guest: Can only view (but cannot view database contents)
Admin: Can perform any operation (only group that can add/delete users)

Potential additions:
Monitor: Guest privileges + ability to generate graphs + turn camera on/off
Editor: Monitor privileges + ability to edit relay/sensor/PID configurations

Any others that would be useful?

If I have multiples Raspb.pi with mycodo on each / multiples setup / multi chambers : it'll be great to be abble to personalise a bit to know immediatly on which one you are.
Perhaps a functionnality to upload a banniere with fixed valors that'll appear in see-through the header (please find example in attached picture)

I used 50% opacity.
Perhaps a small logo at right but I'm totally aware when you add sensors with logs ticked they 'll need this place !

I got an idea - ability to attach photos from RPi camera to notes(made with 'Camera tab')

Turn relay x [on/off] at xx:xx for x seconds (0 to remain on/off)

[selection] repeat x times
[selection] repeat every x [seconds] thereafter)

To turn 1 ON or OFF, the trick is to rewrite the same info in all the boxes before using the button turn on / turn off or delete ! !
need fix ! ;)

I have been using the AM2302 sensor on my projects for some time and it has proven very rugged, reliable and easily mounted in real application. Unlike other sensors, it works via i2c with a static address, so multiple sensors would require an i2c multiplexer. Those are widely available with drivers, but they almost all work the same way. It would be great if Mycodo would support these sensors.

Since the update to the new logging method and history feature, if a value that is printed from the Data tab has a space in it, it will offset the columns and the data columns will not align properly with the name columns. This can be alleviated by not having spaces in values. Therefore, relay/sensor text values need to have spaces forbidden. A warning should be issued if a new value with a space is detected, "Error: Values cannot contain spaces. Please resubmit without spaces."

During a critical failure, event, or measured condition.

I'm trying to set up a makeshift timer for light. So what I did was set turn on relay 1 (normal lights) for 64800 seconds (18 hours). Then I set up a trigger so that when relay 1 turns off, relay 4 (night light) is supposed to turn on for 21600 seconds (6 hours). And another trigger so that when relay 4 turns off, relay 1 is supposed to turn on for 64800 seconds again... so that it does a cycle.

So relay 1 works fine and turns off, turning relay 4 on... but after that, it stops triggering the cycle. Relay 4 turns off, but doesn't write to the log and doesn't trigger relay 1 to turn back on. If I start the cycle from the relay 4 starting point, it does the same thing, except that it logs 4 turning off and turns on relay 1, but doesn't turn relay 1 off, write 1 turning off to the log, or trigger relay 4 turning on.

I'm not sure what the best way to do this is. I would love a time based trigger; so I could put "Turn on relay 1 at 8:00am for ___ hours" or "Turn on relay 1 at ___ and off at ___" would be even better.

Potential features:
Choose what to back up
Choose which commit to update to
Choose which commit to roll back to

Therefore, when one restores a backup and attempts to view the log with the "Restore Log" button, it will print the restore log from the backup and not of the status of the current restore. The status of the current restore will be found in the the system backup that was made as a part of the restore process.

It also appears part of the restore status will be sent to the restore log of the new backup and part to the restore log of the restored backup.

No input defaults to 30, however, any manual input should appear in the input following a submission of a Data tab selection.

Product Webpage
Datasheet

Feature request: When one relay is activated, one or more other relays are activated. This permits the PID controller or a conditional statement could activate more than one relay.

Consider the following simple relay configuration to illustrate the utility:

Relay 1 (Fan), GPIO 10, Link Relay 2 (when Relay 1 turns on, Relay 2 does also)
Relay 2 (Heater), GPIO 15

Relay 3 (Fan), GPIO 10, Link Relay 4 (when Relay 3 turns on, Relay 4 does also)
Relay 4 (Cooler), GPIO 20

Notice that the same GPIO can be set for multiple relays, which can produce a number of conflicts.

What if the same GPIO is trying to be turned on for different durations?
How do the threaded functions to turn on the relays communicate with each other and select the longest duration?

If Both is selected, Up Relay and Down Relay needs to be set.
If Up is selected, Up Relay needs to be set
if Down is selected, Down Relay needs to be set

A warning should be given if any of these are incorrect and the PID is attempted to be turned on.

Rarely, the generation of a graph will coincide with a relay or sensor log being written. This can result in the log not being able to be read and the graph generating without any data as input, causing the graph to be empty.

The relay or sensor log needs to be locked by mycodoGraph.py while the log is being read/parsed.