setpoint chart overshoots edge of chart by a few pixels

[ThermoMan]

That chart is from this data (not the SQL from the code, just everything for Feb 2) SELECT * FROM thermo2__setpoints WHERE switch_time >= '2014-02-02' and switch_time <= '2014-02-03'

1 66.00 2014-02-02 00:00:00 1 58.00 2014-02-02 00:01:00 1 70.00 2014-02-02 00:54:00 1 66.00 2014-02-02 08:52:00 1 72.00 2014-02-02 16:54:00 1 59.00 2014-02-02 23:55:00 1 66.00 2014-02-03 00:00:00

Ouch, when I zoomed in, I see that the cycles also overshoot a bit. Well, one thing at a time.

[unlstorm]

That overshoot is because the 00:00 and 23:59 are not falling exactly on the chart axis's. I tried looking at pchart to see if I could fix that but I didn't see an easy way. If you look at my last set of updates (line ~544 in draw_daily.php) the "$LeftMargin = $graphAreaStartX + (8 / $dayCount);" was an update from the prior implementation. I found that necessary because the 00:00 position would change depending on how many days of data you display in the chart. Looking at a 1 day window makes it look more prevalent. As you add more days the problem isn't near as obvious.

[ThermoMan]

I added and committed a fudge factor that scales the right hand edge. But I'll also look at the left hand side too. The left side is a little different because 00:00 is not at the edge of the chart area while 24:00 is exactly the edge. At least it also fixes the other thing I noticed too.

[ThermoMan]

Ugh, yeah, I see what you mean. The left edge has a dynamic position. But it's not just the data lines, the scale actually slides left too. You can barely make out the dashed vertical line showing the edge of the chart area - I highlighted the location with an arrow. Probably going to have to live with that one. I checked it at 1, 10, and 25 days in the data set. It hits the left margin pretty quickly and then just sits there.

[unlstorm]

I think you should leave this issue open. 24:00 is also not exactly on the end of the plotting edge. If you look at your zoom above you have ticks at 30 mins for the 1 day plot. Compare the spacing between 23:00 and the 23:30 tick. Then look at the remaining distance between the 23:30 and where the 24:00 should be. Based on that I would say the previous code was more accurate.

Try something like this (if you have newest version of pchart): $myPicture->drawScale(array("XMargin"=>10,"YMargin"=>10,"Floating"=>TRUE,"DrawSubTicks"=>TRUE));

When I look at "http://wiki.pchart.net/doc.doc.drawxthreshold.html" it looks like they were able to better align the abscissa to the edges of the chart plotting area.

[unlstorm]

Also of note in your plot. The day should end on 23:59. I see your setpoint change at 00:00? I wouldn't expect to see the setpoint go down on the current day you show above. It should go down on the next day plot.

[ThermoMan]

The actual SQL for that chart is SELECT set_point, switch_time FROM thermo2__setpoints WHERE id = '1' AND switch_time BETWEEN '2014-02-02 00:00:00' AND '2014-02-02 23:59:59' UNION ALL SELECT set_point, switch_time FROM ( SELECT * FROM thermo2__setpoints WHERE switch_time < '2014-02-02 00:00:00' ORDER BY switch_time DESC LIMIT 1 ) AS one_before_start ORDER BY switch_time ASC

and produces these results 59.00 2014-02-01 23:55:00 66.00 2014-02-02 00:00:00 58.00 2014-02-02 00:01:00 70.00 2014-02-02 00:54:00 66.00 2014-02-02 08:52:00 72.00 2014-02-02 16:54:00 59.00 2014-02-02 23:55:00

So ignore the 00:00 on the 3rd that is in the data set at the top

Now this does bring up the issue that I have (with my fudge factor) forced 23:55 to match the right hand side of the graph (23:59) When it ought to be roughly 2.5 pixels to the left..

Also the original author of this included the last setpoint the day before so you can can see a drop/rise happen and what it was as we entered the day.

[unlstorm]

I wrote that SQL statement. That SQL statement is only for getting the setpoint information. The 23:55 is the day before so I can figure out the prior day's setpoint and know how to draw the setpoint leading into the current day. It has nothing to do with the right hand side of the graph (or the left hand side for that matter). I'm also the one that re-adjusted the pixels per inch to be correctly computed based on what should be the plotting area. I think these fudge factors can completely go away if we get the 00:00 to be the start of the plotting area and the 23:59 to be the end.

[ThermoMan]

I am experimenting with this version of the SQL on my system.

Note that there are SIX change points. Two come from manually forcing 70 and 72 degrees in there. The others I think comes from e5. Looking on the Filtrete website I have a simplified setup. 66 10:00 58 23:59

SELECT set_point, switch_time FROM thermo2__setpoints WHERE id = '1' AND switch_time BETWEEN '2014-02-

OUTPUT 66.00 2014-02-02 00:00:00 58.00 2014-02-02 00:01:00 70.00 2014-02-02 00:54:00 66.00 2014-02-02 08:52:00 72.00 2014-02-02 16:54:00 59.00 2014-02-02 23:55:00

Your reply popped up while I was typing. The fact that I have a 00:00 in my data interferes with seeing what your SQL was about. I'll be restoring it because you're right about needing to know where (vertically) that line enters the chart.

Agree wholeheartedly on the scaling thing.

[unlstorm]

Found a fix:

Add this to the front of the $scaleSettings array: ""XMargin"=>0,"YMargin"=>0,"Floating"=>TRUE,"

I still need to make another fix to my left margin but doing the above allows the 00:00 to fall exactly on the plotting boundaries.

Also change this: $LeftMargin = $graphAreaStartX + (8 / $dayCount); to this: $LeftMargin = $graphAreaStartX;

[ThermoMan]

Those look good on my charts.

[ThermoMan]

Rats, the chart cuts off at 23:30 on the right though (when looking at just one day). On the x-axis I think I need to force one more data point to 00:00. I'll poke at it a bit.

[ThermoMan]

Ah, found a fix for that too. Will check in later. Must inspect eyelids for cracks now.

[ThermoMan]

Seems done. Will make sure all code is checked in soon