-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adding optional other sensor values #17
Comments
Hello Colby, I apologize for the slow reply, I somehow lost the email notification. Overall I like the idea to make the module more generic and allow the devices to submit more data that the module can display. Do you have any special data in mind that your devices could send and would like to see on your mirror? That would help us figure out the right data and configuration JSON formats. For example the posted data could be something like this: {
"temp": 27,
"humidity": 30.4,
"battery": 100,
"sensorId": "1",
"ext": {
"pressure": 1017,
"windSpeed": 5
}
} And the corresponding configuration: var config = {
modules: [
{
module: 'MMM-RemoteTemperature',
position: 'top_right',
config: {
sensorId: '1',
icon: 'home',
showMore: true,
extUnits: {
"pressure: "hPa",
"windSpeed": "km/h"
}
}
}
]
} The above is just my first thought, I'm not sure that it is generic enough. For example I don't know if devices can send string data like We can come up with a better name than We should also not forget that you mentioned that you have several devices you want to see on the same mirror. For that I think we should create an optional "condensed" view or just show these new values right after the current temperature and humidity values in the same line, and not add a second line above the "more" line. What do you think? |
No problem. Your timing is actually perfect because just this morning I was thinking about another value I'd like to display (heat index). For the different types of data, I think a simpler approach would save you from having extra code to maintain and be more universal so people can use the two "ext" slots for whatever they want. (And I think "ext" is just fine.) The posted data would be something like
People could then add their preferred labels in CSS like
I also don't think you need to worry about string values. Things like "cloudy" would require more calculation and interpretation than a simple sensor could handle, so I think pretty much any value coming from a sensor would be numeric. For the formatting, I have found that more than two values on a single line is hard to look at. So, I'm guessing most people would want to have a line break between temp/humd and ext1/2. But other people may have different opinions. So maybe you could do the following:
If you happen to have a testing branch I can access, I'm happy to do some beta testing of different format configurations. |
Hello @cweinhofer, I created a new I'm very interested in your opinion. |
Thanks, György. Let me do some testing and I'll report back. |
I've run some tests and here's what I've observed so far:
|
Doing some more playing around and have two further things to report. (nos. continued from above)
|
Hi György, I wanted to check on this to see where things stand? I have been using the feat/extension-fields for a while now and it seems to work fine. I even found another use for the ext fields recently. I started having the microcontroller in my temperature sensors keep a record of the high and low temperatures for each day as well as calculate the heat index using the temperature and humidity. Using the ext fields I can display this below my main temp readout. However, I'm still running into the problem I mentioned in no. 3, above. Because the ext fields don't have their own CSS class, I can't style them individually. In my case I'd like to ad the label (H, L, or I for high, low, index) before each temp ussing CSS rather than after using the field in the module. Also, another smaller issue I bumped into:
Thanks! |
Hi György,
I like the recent changes to module. Both functional and attractive. Seeing them inspired me to rethink my pull request from a few months ago.
Your assertion about very few people ever needing to display both Celsius and Fahrenheit was quite true. But I realized that my my original proposal may not have been bad but simply too narrow in scope. I think the idea could be sound if it could be expanded for a wider variety of uses.
Here's my new idea: What if we added an option in the code to have two extra values displayed directly below temp and humidity and above your new battery and update time? They would use essentially the same code as temp and humidity with just new names.
And like humidity, they would only appear if data was sent to the module. For many users they would be unused -- "out of sight, out of mind" as the say. But for people who have remote units capable of sending other values (for example atmospheric pressure, wind speed, solar radiation level, etc.) they would be available for use.
To help keep things simple and broadly usable, they could be coded as just generic number values and the user would then add symbols/units (like atm or m/s) after the numbers using CSS.
I would be happy to cobble together a pull request for both the code and the readme. Code-wise the changes would be somewhat similar to my pull request from a few months ago, so I don't think it would be too hard to do. But I figured I'd see what you thought of the idea first.
Thanks,
Colby
The text was updated successfully, but these errors were encountered: