Octoprint: More Temperatures in Chart like Room and Air in printer case

[Smuk3D]

Like to see wich temperature has my Room or has the air in the printer case.

actually i look with putty over ssh ...

i have attached an onewire usb modul and owfs running. so i can grap the temp by "cat /mnt/1wire/10.715837010800/temperature" for example.

thanks for your great software...

smuk3d

[mrongen]

Seconded. (This goes right along with multi-extruder support as well.)

[Loopbackconnector]

I would also like the feature to inject lines on the graph (or just a pointer into how to do so). I personally am looking to track room temp, and since I have an enclosure, I also track the temp in the enclosure. I currently have it as a python script, but not put into the one easy to use and view octoprint screen..

[foosel]

Note to self: Add a hook for plugins to provide additional temperature data points. Log that data in the graph, also return it on the API. Needs some way to cope with different sampling rates (e.g. printer data every five seconds but some ambient sensor only every 30a or instead every second)

[grob6000]

+1 on this request!
I've currently got smoothieware outputting my heated chamber on M105 requests, using an identifier of "C". But hosts (including octoprint) ignore parts they don't recognise. Maybe a first step could be plotting every temperature identifier returned by M105 (instead of just T* and B)? Even if you don't provide a set control, showing them all on the graph would be useful in nearly all cases. Example:

Send: M105
Recv: ok T:34.6 /0.0 @0 C:40.1 /40.0 @0 B:80.2 /80.0 @0

Ideally the temperature graph would provide a series for T, C, and B(ed).

[eirikso]

+1 on this request. If possible: read the temperature from a sensor that is connected directly to a Raspberry Pi for those that are running Octoprint on a Pi. You can see my very simple ambient temperature monitor down to the right in this image. I simply put it in there in a space where it is visible from the webcam. :-)

[nonoyo]

Hi all , i'm looking for a way to reach this goal.. i'm student and i wish to add a new sensor to octoprint for my school project. it's about add a smoke sensor and put it on the interface , and i don't really understand how to do..
Please need your help and sorry for posting at the wrong place .

[foosel]

It isn't possible currently since that part of OctoPrint is not yet extendable.

[Smuk3D]

but again +1 to add this function. perhabs only in plugin interface

[nonoyo]

Thanks for helping, do you have any guide or tutorials for help me because i read the information about plugin and other but i don't understand how to build a plugin with informations from an external sensor

[foosel]

i don't understand how to build a plugin with informations from an external sensor

Again, it isn't possible currently since that part of OctoPrint is not yet extendable.

[nonoyo]

Okay, i'll look for an another way thanks for your help again

[Smuk3D]

what you can do is hacking octoprint and add this feature ;-)

[doublebyte]

+1 to this feature too ... I'm making an enclosure so reading the ambient temp would be very useful.

[Norberg]

Considering the interest in this feature I could mention that I made a hack sometime ago which replaces the bed temperature in octoprint with the Room temperature instead. If you are interested you could fetch the code from my room_temp branch or cherry pick this commit: https://github.com/Norberg/OctoPrint/commit/827735ad65c53a0237b6cc413215a7352e340495

What it does is that it fetches the temperature from /tmp/room_temp and prints it in the graph instead of bed temperature. Its however just a hack, and was done on a earlier releases of octoprint so i don't know if the same change would work on the latest release or not. Renaming "Room" or fetching the temperature from elsewhere should be trivial based on my commit.

[Ardrake]

+1 on this request as well

[shirnschall]

Is this possible yet? Would be very nice to see/set the enclosure temp in the graph

[matemat13]

+1: I would also like to vouch for this request... The possibility to monitor cold ends would be nice too. Support for reading the additional temperatures from responses to the M105 GCode would also be great.

[poehlert]

+1 here too. I'd actually like to add 2 temperatures, one for ambient room temperature and one for my enclosure temperature.

[vitormhenrique]

Hi Gina, author of OctoPrint-Enclosure plugin here... a lot of people have been requesting me this feature,

As already support a bunch of different external temperature sensors. A hook that I could set a Label, Value and time stamp would be great.

Let me know if I can help with something.

[AmiableAnteater]

+1

[TobiasWeis]

+1

[maukcc]

+1 on this request. It seems enclosed printers are getting more popular :)

[sidoh]

In case this is useful to anyone else, you can scrape temperatures from the /downloads/logs/serial.log route of the logs plugin API (serial logging has to be enabled). My Prusa MK3 sends the "ambient" (inside Einsy enclosure) and PINDA probe temperature readings in the M105 response.

The serial log is only rolled daily, and so can obviously get quite large.

Fortunately, the logs API tells you the size of the file, and also supports content ranges. So you can easily fetch the last KB quickly:

$ curl -s -H 'X-Api-Key: <key>' 'http://octoprint/plugin/logging/logs' | jq '.files[] | select(.name == "serial.log")'
{
  "size": 19266018,
  "refs": {
    "resource": "http://octopi.sidoh.org/plugin/logging/logs/serial.log",
    "download": "http://octopi.sidoh.org/downloads/logs/serial.log"
  },
  "name": "serial.log",
  "date": 1531539268
}

Then subtract 1024 from the log size and build the appropriate Range header:

$ time curl -s -H 'Range: bytes=19266446-' -H 'X-Api-Key: <key>' 'http://octoprint/downloads/logs/serial.log' | tail
2018-07-14 03:36:18,290 - Send: M105
2018-07-14 03:36:18,305 - Recv: ok T:31.0 /0.0 B:29.5 /0.0 T0:31.0 /0.0 @:0 B@:0 P:30.7 A:36.5
2018-07-14 03:36:23,291 - Send: M105
2018-07-14 03:36:23,306 - Recv: ok T:31.2 /0.0 B:29.2 /0.0 T0:31.2 /0.0 @:0 B@:0 P:30.8 A:36.1
2018-07-14 03:36:28,292 - Send: M105
2018-07-14 03:36:28,308 - Recv: ok T:30.9 /0.0 B:29.4 /0.0 T0:30.9 /0.0 @:0 B@:0 P:30.7 A:36.5
2018-07-14 03:36:33,294 - Send: M105
2018-07-14 03:36:33,309 - Recv: ok T:31.0 /0.0 B:29.4 /0.0 T0:31.0 /0.0 @:0 B@:0 P:30.8 A:36.1
2018-07-14 03:36:38,295 - Send: M105
2018-07-14 03:36:38,312 - Recv: ok T:31.1 /0.0 B:29.4 /0.0 T0:31.1 /0.0 @:0 B@:0 P:30.8 A:36.2
curl -s -H 'Range: bytes=19266446-' -H    0.01s user 0.01s system 28% cpu 0.040 total
tail  0.00s user 0.00s system 7% cpu 0.039 total

I glued some stuff together with Node-RED to get this into HomeAssistant:

(the crazy artifacts in the history are from when i was missing around with the Node-RED endpoint)

[jneilliii]

That would be a good plugin.

[simonvez]

I add my voice to this thread. :) I would like to be able to display this temp of chamber:

#define TEMP_SENSOR_CHAMBER 1

[flo269]

+1 I think it would be very valuable to tinkerers!

[linux01d]

+1 This is very useful feature :)

[JamieAKing]

+1 would love to be able to read and out put multiple additional thermistor values. I would like 1 in my enclosure and 1 in the electronics compartment

[tedder]

No need for more +1s. Just hit the 'thumbs up' on the original message.

[memetb]

Commenting instead of creating a new issue/ticket, but has there been any attempts (anywhere) to integrate with TSDB and monitoring tools (e.g. influxdb and grafana)?

I'm just about to implement a solution like that for my own testing purposes. It is actually much easier to do than would seem. However, I can see there's room for quite a bit of redundancy and poor overall architecture if everyone just does it on their own.

Any comments on this @foosel?

(Note: for the record, I have a PMS7003 particle sensor attached to the Rpi UART, and TMP006 and DHT22 sensors attached to the Rpi I2C. While I don't think it's even appropriate that octopi have the kind of functionality grafana/influx would have - most notably persistence - I think it might be worthwhile to think of a simplified API for just feeding any data to the graph. Under the scenario I imagine, there would be data sources, and there would be loggers that multiplex the data to octoprint + influx + whatever else, e.g. a notification system.
Note2: I know nobody wants to do work for nothing, so this is quite an open ended question and I'm not asking for a feature. I'm asking for opinions with regards to future roadmap).

[foosel]

but has there been any attempts (anywhere) to integrate with TSDB and monitoring tools (e.g. influxdb and grafana)?

Not from my side, no.

[nionio6915]

Another beneficial application of reading and potentially displaying/logging additional thermistor outputs it to be able to verify the output of other thermistors on the printer, and can be used to it assist in building custom thermistor tables, without the use of a multimeter.

I my case, I am trying to verify the output of an unknown thermistor in my silicone bed heater. By enabling the display ADC value output option in Marlin, and by using a spare, 'known good' 3950 100K thermistor taped to the underside of the silicone heater, I can verify the temp readings of the unknown one, of get the correct values and get the necessary table data from the ADC reporting all at one time.

Recv: T:12.60 /0.00 (996.50) B:12.70 /0.00 (996.38) C:12.95 /0.00 (996.06) @:0 B@:0

[Andrei-Pozolotin]

FYI:

1. Marlin finally have "chamber temperature" support out of the box
   https://github.com/MarlinFirmware/Marlin/pull/12201

2. So "chamber graph" perhaps should be standard feature in octoprint, based on parsing of C:22.92

Recv:  T:25.08 /0.00 B:22.50 /0.00 C:22.92 /0.00 T0:25.08 /0.00 T1:0.00 /0.00 @:0 B@:0 @0:0 @1:0

[foosel]

Just blindly parsing new parameters from the temperature report string that are added by one single firmware variant will result in hilarious mayhem considering how fragmented the landscape is. So unless there's also going to be a capability string that goes with this, this won't be turned into a core feature, temperature responses are already a nightmare to parse as is thanks to various interpretations by firmware out there and I don't want to get swamped in tickets by users with firmware variants that have decided to use the undocumented C parameter for god knows what.

[nionio6915]

foosel

is there any way to incorporate memetb's suggestion of having a simple API to inject another datastream into the graph?

would it be 'easier' to create a second graph instance and have it all as user data streams? then we can work out how to interface DHT/SHT sensors or other data devices.

[vitormhenrique]

@foosel other than implementing the firmware I would also think that implementing the hook capability would be better, than other developers could implement custom hooks for different firmwares etc...
And specially for my plugin users would be able to plot multiple different temperature sensors.

[tedder]

It's pretty clear that there needs to be a TSD at the Octoprint level, there are tons of requests for it, as this ticket shows. It's a matter of dev time to build it, which .. foosel is doing her best and the rest of us are kinda on the sidelines, writing plugins and hoping someone else takes the big work.

My point is- if you want this, add a :+1: to the top of this issue. No real need for more "me too"s.

[thinkyhead]

Has it been fully decided what the capability string should be? I'd prefer the shorter CHAMBER_TEMP to save precious bytes of flash for ATmega1280 users.

Alternatively —or as an adjunct— it would be helpful if the capabilities protocol could be amended, so that if something isn't mentioned, then the host assumption should be that the capability is not present. That would allow us to save dozens more precious bytes of Flash for our cherished Melzi users by simply leaving out those capabilities names that are not enabled.

[thinkyhead]

Also, it should be noted that the chamber heater capability is an entirely separate thing from the chamber temperature sensor capability.

[Andrei-Pozolotin]

@foosel Gina: done:
https://github.com/MarlinFirmware/Marlin/issues/13380#issuecomment-472663553
should add chart: CHAMBER_TEMPERATURE be tracked separately
form this ordinal issue add more temperature charts?

[foosel]

Alternatively —or as an adjunct— it would be helpful if the capabilities protocol could be amended, so that if something isn't mentioned, then the host assumption should be that the capability is not present.

In all honesty, that is pretty much how I already have implemented it. Default assumption if no specific report is present (which is usually "not supported"), reported value if it is.

[foosel]

The above commit adds support for chamber temperature reporting & management if supported by firmware.

To quote the commit note:

Chamber temperatures reported via M105 will only be parsed if the
fw reports chamber capabilities (through Cap:CHAMBER_TEMPERATURE:1) or
the currently selected printer profile has a heated chamber configured.
This is to avoid incompatibility issues with firmware variants that
might already use the C parameter for something else (which might be the
case since we don't have a reliable well defined standard that people
need to adhere to...)

Chamber temperature commands M141 and M191 will only be allowed to be
sent if the selected printer profile has a heated chamber configured.
This mirrors the behaviour for the bed temperature commands M140 and
M190 and heated bed configuration.

Display of chamber data in the graph will only happen if the printer
profile has a heated chamber configured.

That should help until someone (e.g. me, or someone sending in a PR) gets around to making the temperature graph extendable. Which - as I found while implementing chamber temperature reporting - might turn out more tricky than I so far thought and need some more refactoring to make it possible.

[tduehr]

Looking through https://github.com/foosel/OctoPrint/blob/devel/src/octoprint/static/js/app/viewmodels/temperature.js seems like changing the assumption that a missing attribute means the temp is zero (e.g., line 235) to a NOP and letting the graphing library handle it is the right route. That's going to mean explicitly sending a 0 for configured sensors without available readings (e.g., the printer main power is off).

Is that right @foosel ?

[foosel]

I think I'm not following. The right route for what? Injecting temperatures? That would have to start down in the backend.

[jneilliii]

@foosel I'm willing to throw in some dev time on this request if you haven't already started, it seems pretty challenging and I think it would be kind of fun. If I remember correctly you are currently using flot for the graphing right? Are you opposed to switching to other libraries like plotly or similar?

[foosel]

@jneilliii Not opposed. Shouldn't break any plugins yet as there's no documented extension point there.

The whole request is more backend than frontend focused though I fear. Finding good solutions for the API endpoints and the internal temperature data collection for additional values. Injection point for plugins should maybe be a hook, though there'd need to be a solution for different sampling sizes.

[jneilliii]

I'll look through your changes you did for the chamber changes and see if I can understand how your doing it now. It seems a plugin hook for adding additional data would be the way to go, potentially pushing into a queue of data that the backend plots.