EventGhost

And did you see this difference?

max-width

Smart, thanks! Didn't think of that! Which is probably why I'm asking the questions and you are answering them!

I have found something that works, but the graphs are getting a bit small. But I think the solution (at least for me) would be to be able to run a negative margin on the upper div (the rose), so that moves to the top, without removing the back button. The problem is that I only know how to do that in CSS, and not in regular HTML style, and I'm working in Notepad++. I tried marginheight: -400px, but it doesn't take. Would it be possible to add a reference to a CSS in the code? Then I could use my own CSS to style both the div called container and the dive called Wind_gust. That could be useful for other graphs too, so I can have humidity and temp on the same page and use a CSS file that doesn't change to size them. Would that possibility be much work to add? And then just have an empty CSS file distributed with the plug-in, so nothing fails looking for the file. Please?

Well, anything is possible for vikings...

You could try to edit a created report html in Notepad++ until you think it looks ok (I mean add the css stuf as you like and try it out) Once you have it, I can add an empty stub in the "official code"

Of course! Vikings never stops for anything! Thanks a lot! So now I have a CSS, but I have also made a few changes to the actual page, if you don't mind.
is that OK by you? I don't know if it's possible to make code that adds a CSS file with the standard stuff if no CSS file is found? As for my CSS for this, here's what I have so far:
That looks pretty good in my system.

Haven't tried yet but if it looks fine, why not make it "The Standard", I would not mind, everything that makes it better is fine I think!

So Thank You!

BR Walter

You could make it easy for me to adopt, mail me your py files

Great! But I have to admit I misunderstood... I modified the HTML files directly, and not the py files...

Then send me the html files, they will help partly

Ding! You've got mail.

Latest release 0.5.0 now available for download

- Added support for Barometric pressure data capturing & reporting (requires a RFXtrx and sensor type BTHR918, BTHGN129)
- Added support for a new type of report allowing you to create reports with a daily wind rose (WindMiniRoseReport)
- Further improvements of report layouts using css (thanks Mastiff)
- Modified layout of Wind Rose report

Great, man! This plug-in is so cool, nice to follow the temperature in both rooms and outside, and it always impresses visitors too!

Walter,
I've been using your successful plugin for some time now and wondered if you would consider two timing thoughts/requests.
I use the Temperature related section mostly and use the Rule ==,<,> TriggerEvent to run scripts to control my heating.
From my limited code skills I believe the timing of the RuleEvaluator is coupled to the Database update.

Would it help and give greater flexibility to...
1. have the RuleEvaluator called on its own time interval set in the config so that it can be more frequent and allow more options on database mgt.
2. enhance the condition for Rule trigger to CreateEvent only if res <> lastCommand. The request is to have a maximum elapsed time or a number of occurrences (also in config) before the triggered Rule Event is forced? This would give more scope to manage dependencies on the triggered event, rather than just when the rule output changes.

If this already achievable can you help point me in the right direction?
Many thanks

Hello jenno,

Yes, you are correct, the rule is checked when the database is updated. The lowest time interval for updates is once per minute, i.e. if you have a sensor that sends an event at that rate (like Oregon, they send approx once every 45 seconds) the rules will be checked every minute.

Regarding your requests

1) Would require a major re-work, eventually by adding new actions having that functionality, keeping the old ones for backward compatibility. But anyway, rather lot of work. With current solution, you can make the rules to be checked once per minute, why is this not enough for controlling heating systems?

2) This would be much easier to add. I think a time based triggering would be more reliable & accurate since it can happen that events might be missed. Easiest would be a hard coded value, lets say every 15 minute the event is triggered with the latest condition. Every time a new condition is calculated, the timer will be cleared & restarted. Having a setting for the time interval in the configuration dialog is also easy but might break backward compatibility, i.e. you may have to delete the existing actions for temperature capturing and re-create them

To be discussed further

Best regards, Walter

Morning Walter, thanks for your quick response, sorry for the delay in responding, I've been experimenting.
At best I'm a good plagiarizer rather than a programmer so my code is rather inelegant.

The reason I've asked for your thoughts/help is because we have a varied time/heating pattern throughout our week. I wanted to include a time forced Rule and associate it with a variable "setpoint". I would read the setpoint from a new table within the tempData.db (override options later) with by day by hour entries. This helps with our variable/holiday/hourly reactive family life. With a few simple phone webpages and a vpn I can then remotely control the setup when having to change our daily routines.

I was OK with setting up the setpoint functionality as I saw this as a discrete piece of code which I could include in any plugin updates. However I was concerned that the Rule management/database update might either conflict or hopefully be viewed as a generic requirement/feature.

Back to the 2 points.
Ref point 1) I understand your response and gave more thought to 2). and used some global variables to experiment.

Ref point 2)
2a I setup global variables for "ruleTimer" the default Force value, "ruleEvent" time of last rule, "elapsedTime", "ruleReset" override to ruleTimer. I know some of these could be derived but I wanted to capture and manipulate their values. The default values were set in Main.OnInit and other scripts to force the rule in different scenarios and testing. In doing so I didn't need to keep changing the plugin
2b within the plugin I used the ruleEvaluator for every sensor value captured and added new time based conditions using the g.vars when processing the rule.
2c I set the plugin interval to 20mins for database updates with the existing exception conditions.

So far the branched code is doing the job.

I know you help many of us on the forum, thank you v.much, and have a variety of requests. However, if you do think the Rule Timer is of benefit to the plugin then I'd be happy to help test any developments.

Obviously the market is now responding to heating efficiency with commercial products, but they wouldn't have tested my aging brain in retirement!
Regards
Jenno