That’s a pretty simple change. I’ll probably squeeze it in sometime today.
1 Like
I think it would be cool to be able to perform some basic math on ds18b20 values in place of just an offset and set a custom unit name.
This could allow people to use homemade sensors or non 1wire sensors and send the data to brewblox on an emulated ds18b20 using an Arduino and existing emulation libraries. I would love to try to add humidity, load cell, flow rate, etc. sensors to my brewblox homepage. Or at the very least, allow people with crappy ds18b20 sensors to calibrate more accurately.
If I understand this correctly, you want to plug various devices into the spark, have the spark read raw values, and post-process externally?
I’m not familiar with the ds18b20 spec, but this sounds like we’d want to split any implementation in two parts: firmware support for reading/writing raw values, and custom post-processing.
Timetable and viability of firmware implementation depends on the spec.
Post-processing raw values (and setting the unit string) is possible, but anything more complicated than "multiply value by X” requires a separate service.
Our policy for third-party or homemade devices is that we offer support, tooling, and a service framework for development, but will not officially maintain it.
Could you offer some concrete examples of what you’d like supported? Is advanced functionality something you’re able and willing to develop?
Yes, I think what you are asking for has nothing to do with OneWire temperature sensors. Trying to implement it by bolting extra stuff onto the OneWire sensor class seems like the wrong approach.
The Spark also has RS-485, which is much more suitable to talk to other microcontrollers. We’ll probably use the modbus protocol and will have to come up with a protocol for external sensors. This is definitely on the roadmap, but after we move out of beta.
The 485 would be ideal in the future… Nevertheless, what I was getting at is, instead of allowing a simply offset (addition and subtraction) to the ds18b20 raw value, be able to specify a simple equation (displayedValue = rawValue*0.9 + 1.2 for example) and perhaps set the unit string.
If I understand correctly, you want to use the following configuration:
{
"unit": "lightYears",
"calculation": [
["*", 0.9],
["+", 1.2]
]
}
Output when read (raw value == 8):
{
"value[lightYears]": 8.4
}
Pretty much, the idea would be that you would have a input box on the config where you can input “5.6X*0.78 + 8.6/X - 1.2” where X is raw value.
Feature seems pretty clear then. I’ll make an issue for it.
No guarantees on if, when, and how it’s implemented - the backlog is pretty big, and we may well decide to merge it with a different feature.
Awesome! 
In the legends tab of the graph settings dialogue it would be awesome if you could also specify colors for each metric.
I would like the colors for each variable to be more consistent over multiple graphs/dashboards. Unless I’m mistaken, at the moment, the colors that are assigned appear to depend on the order I add the metrics in.
Right now, colors are picked automatically by the graphing framework (Plotly), but I’m reasonably sure we can override that.
I’ll have a look tomorrow. If we can add it to the Plotly config it should be pretty simple.
1 Like
Great, thanks!
In the longer run, I feel like there is potential for defining default labels and colors for various metrics at a higher level.
It may seem like more of an issue now when new features are coming out regularly and I’m creating new widgets and dashboards, but I feel like I spend a lot of time configuring labels that I have already configured multiple times on other graphs. Once new features slow down, having to replicate the labeling process a few times during a one-time set up may not feel too burdensome. That said, the ability to define system-level default labels/colors would still be a cool feature at some point.
Thanks, I agree that we could try to manage display names and colors in a central place.
However, different charts might want to use different names too.
We already discussed last week to implement better default legend names, beer 1 temp - value instead of spark-one/beer-1-temp/value[degC].
If you have a chart for a single process, you might want to use the name beer 1 temp and beer 1 setting, but for an overview chart, just beer 1 might be enough.
Would if be possible to have user definable global default labels/colors that could would prepopulate the settings for new charts but could then be overridden by local settings specific to that chart?
Another (hopefully very simple to implement) idea. Allow fridge titles in the process view to be definable hyperlinks to other dashboards. For example, if I click on the fridge title in the process view it would take me to another dashboard with more details for that process.
1 Like
Directly including hyperlinks embedded in SVG is a bit of a hassle, and we chose to avoid making the entire fridge / kettle clickable (makes it less obvious that parts inside the fridge are clickable).
What we can do is to add a clickable URL part. It’s something that could also be used to provide easy links to documentation pages.
A URL part would be perfect (for other uses as well). I could just layer it over wherever I wanted to be a link.
Option to (or automatically) disable brewer builder tab switcher when it is only used to display one view. In this (probably fairly common?) usage case it takes up vertical space without adding any value.
Automatically hiding the selector may work. I’ll try it out today.
1 Like