Page 1 of 1

Using room occupancy as a profile variable

Posted: Fri Jun 23, 2017 1:48 pm
by jerry
Does anyone know how to set up a profile to include room occupancy as a variable?
I am currently setting up a model template for carrying out overheating analysis to the TM59 methodology, which requires windows to open when the room is occupied and the air temp >23 deg. It should be easy as you need is something like this: "ta>23 AND occup=TRUE" but you can't access occupancy as a variable in VE so you have to write a different opening profile for each of the 5 room different occupancy patterns, manually defining the occupancy period within each separate opening profile. It's extremely annoying as the occupancy count is obviously available as a variable within VE, they just haven't given the user access to it.
Jerry

Re: Using room occupancy as a profile variable

Posted: Fri Aug 25, 2017 7:32 pm
by toemoss
Maybe the CO2 variable could be made to work for your application?

Re: Using room occupancy as a profile variable

Posted: Mon Aug 28, 2017 3:41 pm
by PCully
Hi,

Occupancy typically follows a fixed schedule and isn't a calculated variable in the simulations so it should be possible simply to define the schedule of your opening profile to follow the occupancy schedule (i.e. apply this profile between 9-5). I appreciate you just want to do it as another variable but I believe the list of variables available is restricted so as not to bloat simulation files etc and also it means you will be able to keep your formula neater which aids understanding if you return to it at a later date or troubleshooting if it is not responding as expected (on that note, when you simulate your MacroFlo make sure you reduce reporting interval from 60mins or it won't look like it is working properly)

Phil

Re: Using room occupancy as a profile variable

Posted: Thu Mar 29, 2018 3:39 pm
by jerry
Hi Phil
I've only just seen this reply. I don't really understand why IES isn't helping users to implement the requirements of TM59, and my suggestion would be very helpful indeed. As would the automatic production of a TM59 report, in the style of the current TM52 report. Life is made even more difficult for the user wishing to carry out TM59 analysis at present thanks to a range test function that can't cope with a time period that crosses midnight (as I'm sure you know, TM59 requires a count of hours of temp excedence for bedrooms during the period of 2200-0700, at present the user has to do 2 range tests, one for 22-midnight, another for midnight to 0700, then sum the results. This is crazy. Good software should aim to make life easier for users by automating such procedures.