A bunch of feedback/suggestions

[fry42]

Hi,

I've been tinkering around with various setups and mycodo for a few weeks now and thought I'd give a little bit of feedback. I'm totally aware that there are many different scenarios, so my findings are purely subjective and I don't claim that they are universally applicable.

• Menu structure/start page
  Mycodo always opens with live measurements - which I never use, because my dashboard has all the gauges&graphs I need.
  The dashboard, which I always look at, is hidden in a sub menu and takes two clicks to open.
  On the other hand there's the data menu which is mainly used for setting up the system but not really afterwards. Camera is also hidden in a sub menu, but if you use a camera as "visual monitoring" it is almost as important as the dashboard.

So while I do understand the logic behind the current structure I think there are improvements possible.

My suggestion would be something like this:

- Dashboard
- Camera
- Live
- Async
- Setup
	- Data
	- Calibration
	- Output
	- Function
	- Timer
	- Methods
	- LCD
- More
	- Export/Import
	- Output Usage
	- Output Usage Reports

This way you would have all monitoring on the first level.
I don't claim that this is THE solution, just thought I put it up for discussion...

• Camera
  Settings page:
  If you set up a "picamera" camera chances are you are using a V1 or V2 Module.
  So it would make sense to add the supported resolutions of these cameras in some way. Maybe it's enough to add it to the help pages (or a link to the picamera documentation).

Is there any reason why you set use_video_port for capturing still images? I manually changed that because the image quality is way better (at least using the V1 module).
Would be nice to have the option on the settings page. Also setting manual white balance would be useful for timelapse recordings...

Camera page:
Currently there is no file management for photos within mycodo.
Personally I don't need it because I just use smb for accessing the folders, but It could be a nice addition for future versions to have a listing of all available photos, ability to download/delete, ...

What I'm really missing is the ability to take a still via the timer interface. For me this makes much more sense than the Interval based system. Especially since it is also available in the Conditional Functions (which didn't list my camera in action=>photos, last time I checked...)

• Manual data aquisition & Comments
  I played around with using mycodo to monitor the fermentation of fruit (making Schnaps :) ).
  pH and sugar content play a big role in this but can't be automatically measured. So it would be a nice feature to define "manual inputs" to record external measurements. Configuration would just be the name of the measurement and the units used.
  For adding manual measurements I'd suggest a dashboard object with just a time/date & value input.

Some form of comments/logfile would also be useful, I think this has already been discussed somewhere...

• UP&Download Backup
  Most users are used to have the option to download and upload backups within the web interface. Personally I do this via ssh... Just thought it would be a "nice to have"...

• Calibration
  When I first saw the calibration menu I was a little disappointed to see that it only relates to the pH sensor.
  It would be great to have the ability to calibrate other sensors as well. The most simple approach would be to just add an offset to a measurement.
  i.e. to sync different temperature sensors so at least they start off with the same value.
  There are many ways to calibrate different sensors, like humidity sensors using different salts, which could be added later on...

• Inverted PWM signal
  Meanwell LED Drivers use a 10V PWM signal. So you can either generate the 10V with a seperate VREG and switch it via PCH transistors or just pull the line to ground with some N-channel transistor.
  This makes the electronics part a lot simpler but has the effect of inverting the PWM signal. High becomes Low, 90% on becomes 10% on. So it would be nice to be able to also invert the signal in software, just like the "On Trigger" High/Low for On/Off GPIOs.

• activate/deactivate PID via timer
  It would be nice to be able to activate/deactivate PIDs via timers. i.e. if you only want to run active cooling during the daytime fore noise reasons.

• Timespan "switch off" option
  At first it confused me that a timespan does not switch off the output at the end. Lucily I read the fine help pages and found out about the logic behind it :)
  I still think a simple option checkbox "Switch output off after timespan" would eliminate the need to have a seperate OFF-timer and new users would instantly understand what's going to happen.

• more integration of alerts and data sources
  Currently alerts are configured as a conditional function. But since every aquired data has a potential of showing something going wrong it could make sense to integrate the alerts directly in the data setup.
  i.e. when I add "Raspberry Pi: Free Disk Space" chances are I want to be alerted if it gets below x MB. So having a checkbox "Alert me if value goes below/above X/Y" would make sense and clean up the function page. A separate "Alarms" menu might also be useful...

Again, these are just my 2 cents, put up for discussion...

Btw.: totally excited about the adition of the MiFlora sensor!

Greetings!
S.

[kizniche]

Thanks for the great feedback. I like to see requests that both make sense and are easy to implement. I'll go through your list and let you know what I think.

Mycodo always opens with live measurements - which I never use, because my dashboard has all the gauges&graphs I need.

The reason I start with the live measurements page is because there's a notification if no Inputs exist, instructing the user to add sensors on the Data page. This would be more helpful to newbies rather than just seeing a graph page instructing the user to add a graph (for which no measurements could be put on). I see an alternative to this issue being the ability to select the landing page. I'll add an option to select the landing page in the configuration.

So while I do understand the logic behind the current structure I think there are improvements possible.

I like yours better than the current. I'll incorporate the new structure.

So it would make sense to add the supported resolutions of these cameras in some way. Maybe it's enough to add it to the help pages (or a link to the picamera documentation).

I don't want to be too restrictive (such as having a dropdown for pre-selected resolutions). I'll improve the documentation for this.

Is there any reason why you set use_video_port for capturing still images?

I believe it's a remnant from when I first started working with the picamera module and was just dropping in others' code to get something working and never revisited it. It has applicability with the streaming module, but it doesn't appear so for the still image capture. I'll remove it.

Currently there is no file management for photos within mycodo. Personally I don't need it because I just use smb for accessing the folders, but It could be a nice addition for future versions to have a listing of all available photos, ability to download/delete, ...

I seldom think about this, but when I do, I realize it's just easier using SFTP/FTP than to build an in-house image navigator. I'll see if there's anything pre-made that I can just drop into Mycodo.

What I'm really missing is the ability to take a still via the timer interface. For me this makes much more sense than the Interval based system.

I'm planning to have conditionals take the role of timers. It seems to me to make more sense because the action framework is already there, and a timer is merely a conditional by another name.

which didn't list my camera in action=>photos

That's a bug. I'll fix that for the next release.

Inverted PWM signal

Nice. Added to next release.

activate/deactivate PID via timer

This comes back to conditionals taking the place of the current iteration of timers.

Timespan "switch off" option

I'll probably add this once I implement timer functionality for conditionals.

more integration of alerts and data sources

I'd like to refrain from redundancy, and I think if I begin going down the route of building conditional functionality into Inputs/Math/etc. it might be confusing to new users. I'd be more inclined to merely add better documentation.

Thanks again for the feedback. Let me know if you have any other ideas or responses. I'll be pushing the edits I mentioned above, shortly.

[frodus17]

Would it be possible add a button to change a PID setpoint within the Dashboard PID widget? I routinely have to change temp manually, and it'd be nice to do that. You set activate/deactivate, pause and hold there, which is nice.

[kizniche]

That sounds like a nice feature. I'll include it in the next commit.

[kizniche]

I think I managed to port all Timer functionality into Conditionals, and removed all remnant Timer code. This expands the possibilities to unfathomable levels... of new issues, and probably a few useful configurations that may work as well.

[Theoi-Meteoroi]

Kyle, do you have any sort of software harness or mechanism you use for regression testing things like the conditionals code? I’ve done a fair bit of test engineering and for the complexity of Mycodo - you have done pretty well with overall stability and service access (log viewers, etc.). I like to help as I can with defects or problems with integration because it might help you roll the ball forward faster. You seem to really shine with the developer’s hat on but work bug reports in earnest. That is not as common with developers as one would hope. You deserve some recognition for that. Most folks just step back as soon as it doesn’t repeatedly “abend” (abnormal ending) as the mainframe guys used to call it. I know. I was the guy the users called when it went tango uniform for them. Looking forward to the next release! I hope the other users know about the Zenodo repository. Unless I’m using the built-in upgrade, I prefer to get my release images there. Its easy to pick down-rev versions if I need to build a controller that has known characteristics and/or documented work-arounds. I’ve had trouble with Mycodo releases I’ve pulled from Github in the past, and that one regression with MH-Z19 has me wondering about them again. Another tool I use to actively follow Mycodo development is GitKraken. I can review your code changes and keep a local up to date clone. I think Mycodo is still pretty much the coolest thing I work on, I only wish I had more time to contribute. Datacenter stuff seems boring in comparison.

…

On Apr 15, 2018, at 3:16 PM, Kyle Gabriel ***@***.***> wrote: I think I managed to port all Timer functionality into Conditionals, and removed all remnant Timer code. This expands the possibilities to unfathomable levels... of new issues, and probably a few useful configurations that may work. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#444 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APsXKn8AInTyqWPr06dmTQqaN1U09O6Zks5to8a_gaJpZM4TLBob>.

[kizniche]

Unfortunately, only input modules are tested. This was implemented not too long ago by someone else, and I wasn't familiar enough to expand it beyond the basic use for the inputs and a few flask endpoint tests. I would like to have good testing coverage, but I'm pulling myself in so many different directions, testing often gets put on the back burner because I'm better at other areas, and I often think that if I'm not going to (or unable to) implement it in a decent way, I'd rather wait until I can learn more about it. Unfortunately, testing is still largely a black box to me for how to implement it into things like the frontend and daemon.

[kizniche]

I revisited the form submission that gave me trouble the last time I attempted to get a frontend test of adding inputs working. I figured out the issue and built the first big test of manipulating the frontend, which includes testing if every input can be added (48 so far). I found an issue with one input addition (SHT1_7x) in the course of this, so it has already paid off in finding bugs. On a Pi 2, it took 202 seconds to complete this test.

Mycodo/mycodo/tests/software_tests/test_mycodo_flask/test_endpoints.py

Lines 137 to 153 in b46f3fe

	def test_add_all_inputs_logged_in_as_admin(_, testapp):
	""" Verifies adding all inputs as a logged in admin user """
	login_user(testapp, 'admin', '53CR3t_p4zZW0rD')
	input_count = 0
	for each_input, each_data in DEVICE_INFO.items():
	response = add_input(testapp, sensor_type=each_input)
	# Verify success message flashed
	assert "{} Input with ID".format(each_input) in response
	assert "successfully added" in response
	# Verify data was entered into the database
	input_count += 1
	assert Input.query.count() == input_count, "Number of Inputs doesn't match: In DB {}, Should be: {}".format(Input.query.count(), input_count)
	input_dev = Input.query.filter(Input.id == input_count).first()
	assert each_data['name'] in input_dev.name, "Input name doesn't match: {}".format(each_input)

[kizniche]

That's actually a huge achievement, considering that unlocks the ability to now test all form submissions.

[mrplow]

How would I set a daily timer to switch a relay on for 12 hours?

I set a conditional Timer (Daily) with a start time of 10:00 (it was past then when I created the Conditional) with a Duration of 43200 seconds.

After activating the relay did not turn on.

I'm assuming it will start operating correctly tomorrow at 10:00? I'm guessing the timer didn't trigger because I created it after it's start time. Is this a correct assumption?

Thanks a lot! I'm really enjoying this project.

[kizniche]

You are correct. It will only trigger the actions at that specific time. If you want it to be on currently, calculate how long the output needs to be on for the remaining time until you want it to turn off, then turn that output on for that duration from the Output page.

[kizniche]

In the future, I will create a duration timer conditional that ensures the output is in the set state for that duration (even after a power outage). Currently a power outage will disrupt the timer Conditionals.

[mrplow]

Excellent, I'm glad I understood correctly.

No prob, I just plugged it into the wall for now and I'll pull it at 10:00. "Manual" labour for one day isn't a big deal.

[kizniche]

@mrplow I added a Time Span Conditional Timer to the latest release, so you can ensure your Output is in the correct state throughout a duration. Make sure you set a Time Point conditional after the end to turn it off (or on) to counter the Time Span Timer. See the manual for more info about this conditional.

[mrplow]

Thanks @kizniche. I had already upgraded and created the conditional but didn't think about creating another to turn it off.