ViewStat Scheduler Update!

vining

ViewStat Scheduler Update!

I posted this here so any one w/o access to the "ACE" only areas can use if desired.

Here's an updated version of the scheduler. A few minor modifications were made to debug and a for loop was added when checking for matching "hold" hours because the line wouldn't work w/o it and it was out of the scope of the for loop which was supposed to affect it. There were some minor appearance changes in this and the previous TP file as well.

So here's the complete zip w/ changes. I don't see any bugs in this version and everything appears to be running smoothly. If you use it, enjoy and let me know what you think or if you find any quirks.

DavidR

sorry but this doesn't compile.

it says perimeters expected are 9 but 8 found. any ideas?

your schedule pages look great btw.

vining

Sorry about that!

I neglected to update the .axi. This was the original axi file and I since added the debug variable nVST_Debug to pass to the module which is a module paremeter as defined in the module but wasn't in the axi to be passed. There's a couple other changes in the axi so just scrap the old and use the new.

I've updated the axi in the zip and it should compile fine now. It's just a pain keeping track of these files cuz I have my working folder and the folder I keep this stuff in for posting is sperate. So I updated the TP and the MOD file but not the include.

I'm glad you like the TP page but wait til you get it working, it's pretty intuative, has nice prompts and very user friendly. I may be biased but I think it's pretty cool!

DavidR

it works now.

can't wait to try it.

thanks for the post

vining

I just finished the xml to var, var to xml, writing to ram and reading from ram stuff so it nows effectively persistent. I'll update the zip or just post a new one with these additional functions and modifications either later tonight or sometime tomorrow. They didn't take long to do (I already had read and write functions written) but between this and a full day of paperwork and other crap I think it's time for a break.

vining

Here's the updated version that uses xml_to_var to write to ram and to read from ram on start up or reboot to make the stored values effectively persistent.

Values are not written to ram on every save but only upon exiting the scheduler. On save values are stored in the structure, on exit the structure is written to ram.


Attachment Removed!

DavidR

tried it yesterday...

i did a quick test with this code yesterday and had some issues.

- the down buttons on both heat and cool do not seem to work.
- the stat names don't populate the name fields on the schedule page.

i changed the port from 18 to 5 but that shouldnt have an effect.

any ideas?

vining

First of are you using the latest version using XML_TO_VAR to save settings to Ram or a previous version?

Do the buttons work as single pushes or are you having problems w/ the hold & variable repeat timeline?
If it's just the down arrows for heat and cool verify that the channel port number indeed changed to 5 and the channel numbers are both correct. Check the address port for the STAT names as well.

If the only thing you did was change from TP port 18 to 5 the buttons should work especially if the up arrow buttons work. The T-Stat names could be one of two possibilities, first being the address port not being changed properly and the second being the structure fields didn't load.

Open debug and copy the structure name sVSTSTAT from inside the modules code and paste it into the Debug var field and check the structure's fields to see if they were populated on start up with values and defaults. I don't think I tested to see that if the xml file wasn't found on the ram at start up that it would go ahead and load the default initial values (just assumed it would work). So depending the version this may be an issue. If you are using the XML version you have to use to the axi file that's with it.

DavidR

only using what is in your zip folder. are there other support files i need?

the up buttons for heat and cool both work fine for push and hold.

the downs do not work at all.

vining

Was that the one you originally downloaded or the lastest one that uses XML.

Oh, read my previous post as I edited it while you made your last post.

DavidR

your latest is what i tried

vining

I looked at the start up code and it the function below would return true no matter what it found or didn't find so it's been modified and the following function was modified as well so that is just looks for return TRUE or FALSE (1 or 0).

In short the first time this code is run it was supposed to load defaults values but then I added code to write stored values to ram to make it in a sense persistent and then when the program is uploaded or the system is rebooted again it would read from ram and not load the defaults. I never tested since having the file on ram to see if the default would load on initial start up. So I delete that file and sure enough the defaults didn't load because the below functions weren't modified for this conditon.

Replace the existing functioins with these and you should get T-Stat names and all initial defaults displayed.

DEFINE_FUNCTION INTEGER fnVST_FileRead(CHAR icReadFile[])
     {
     stack_var slong nReadFHandle ;
     stack_var slong nReadFResult ;
     
     nReadFHandle = file_open(icReadFile,FILE_READ_ONLY) ;
     if (nReadFHandle > 0) 
	  {
	  if (nVST_DeBug)
	       {
	       SEND_STRING 0,"'FUNCTION fnReadFile. File_Open successful for *',
					     icReadFile,'*! line-<',ITOA(__LINE__),'>',crlf" ;
	       }
	  nReadFResult = file_read(nReadFHandle,cVST_Var_to_XML,VST_READ_BUFLENGTH) ;
	  if (nReadFResult > 0) 
	       {
	       if (nVST_DeBug)
		    {
		    SEND_STRING 0,"'FUNCTION fnReadFile. File_Read OK. Rcvd: a ',
					     itoa(length_string(cVST_Var_to_XML)),
					     ' CHAR String!  line-<',ITOA(__LINE__),'>',crlf" ; 
		    }
	       }
	  else
	       {
	       stack_var char cErrorMsg [20] ;
	       switch (itoa(nReadFResult)) 
		    {
		    case '-9': {cErrorMsg = 'end-of-file reached'} ;
		    case '-6': {cErrorMsg = 'invalid parameter'} ;
		    case '-5': {cErrorMsg = 'disk I/O error'} ;
		    case '-1': {cErrorMsg = 'invalid file handle'} ;
		    case '-0': {cErrorMsg = 'zero bits returned?'} ;
		    }
	       if (nVST_DeBug)
		    {
		    SEND_STRING 0,"'FUNCTION fnReadFile. Bad Read_File: ',cErrorMsg,
						  '! line-<',ITOA(__LINE__),'>',crlf" ;
		    }
	       RETURN FALSE ;
	       }
	  file_close(nReadFHandle) ;
	  }
     else
	  {
	  stack_var char cErrorMsg [40] ;
	  switch (itoa(nReadFHandle)) 
	       {
	       case '-2': {cErrorMsg = 'invalid file path or name'} ;
	       case '-5': {cErrorMsg = 'disk I/O error'} ;
	       case '-3': {cErrorMsg = 'invalid value supplied for IOFlag'} ;
	       }
	  if (nVST_DeBug)
	       {
	       SEND_STRING 0,"'FUNCTION fnReadFile. Bad Open_File: ',cErrorMsg,
						  '! line-<',ITOA(__LINE__),'>',crlf" ;
	       }
	  RETURN FALSE ;
	  }
     file_close(nReadFHandle) ;
     RETURN TRUE ;
     }

DEFINE_FUNCTION CHAR fnVST_LoadStartingValues() 

     {
     stack_var slong nVST_READ_OK ;
     
     nVST_READ_OK = fnVST_FileRead(VST_XML_FILENAME) ;
     if (nVST_READ_OK)
	  {
	  stack_var sinteger nXML_Decode_Return ;
	  stack_var char cXML_MSG[100] ;
	  stack_var long nVST_POS ;
	  
	  if (nVST_DeBug)
	       {
	       SEND_STRING 0,"'ViewStat_Module: Loading RAM FILES: Line-<',ITOA(__LINE__),'>',crlf" ;
	       }
	  nVST_POS = 1 ;
	  nXML_Decode_Return = XML_TO_VARIABLE (sVSTStat,cVST_Var_to_XML,nVST_POS,0) ;
	  if (nVST_DeBug)
	       {
	       switch (itoa(nXML_Decode_Return))
		    {
		    case '-1': {cXML_MSG = 'ERROR -1 = decode variable type mismatch' } ;
		    case '-2': {cXML_MSG = 'ERROR - 2 = decode data too small, decoder ran out of data. Most likely poorly formed XML.' } ;
		    case '-3': {cXML_MSG = 'ERROR -3 = output character buffer was too small' } ;
		    case '3' : {cXML_MSG = 'ERROR 3 = XML decode data type mismatch' } ;
		    case '2' : {cXML_MSG = 'ERROR 2 = XML decode data too small, more members in structure' } ;
		    case '1' : {cXML_MSG = 'ERROR 1 = structure too small, more members in XML decode string' } ;
		    case '0' : {cXML_MSG = 'Returned 0 = decoded OK! ' } ;
		    }
	       SEND_STRING 0,"'ViewStat_Module: XML Loading: ',cXML_MSG,' Line-<',ITOA(__LINE__),'>',crlf" ;
	       }
	  }
     else
	  {
	  fnVST_Load_ZoneNames() ;
	  fnVST_Load_Defaults() ;
	  if (nVST_DeBug)
	       {
	       SEND_STRING 0,"'ViewStat_Module: Bad XML File Read ! Line-<',ITOA(__LINE__),'>',crlf" ;
	       SEND_STRING 0,"'ViewStat_Module: Loaded STRUCTURE from General Deafaults: Line-<',ITOA(__LINE__),'>',crlf" ;
	       }
	  fnVST_LoadAdmin_SetPoint_Defaults() ;
	  fnVST_LoadZones_SetPoint_Defaults() ;
	  if (nVST_DeBug)
	       {
	       SEND_STRING 0,"'ViewStat_Module: Loaded STRUCTURE SetPoint from Defaults: Line-<',ITOA(__LINE__),'>',crlf" ;
	       }
	  }
     clear_buffer cVST_Var_to_XML ;
     
     RETURN TRUE ;
     }

vining

Zip contains ViewStat Scheduler TPD4 files for CV7 and the MVP8400.

vining

Note: if you ran the code prior to changing the previous listed function you will need to update the functions to the ones listed and you must also delete the file created and written to RAM. (Unless your still using the pre XML version.)

As long as that file is on the RAM the initial defaults will not be loaded into the structure and when the scheduler is exited and the structure is written to RAM missing values in the structure will also be absent in the file.

Unless I change the code and do comparisons of the XML file to the defaults values any changes in zone names, or defaults in the includes files constants will also require that file to be deleted as well so that the new values will be loaded and subsequently written to RAM.

vining

Yet another update!

This update fixes some issue mentioned in previous posts.

On initial start up the functions will now load the defaults. When the user exits the scheduler the structures data is written to RAM in an .xml file. On subsequent program uploads or reboots the structure values will be loaded from the .xml file making the values persistent.

Added a persistent VAR to keep track of the amount of zones that were loaded into the structure in previous uploads so that if changes are made in the number of zones and a new program is uploaded it will test for changes and update the structure has needed. If you add zones the previous existing zones will still get populated by the values contained in the .xml file but any new zones will be loaded with defaults. If you decrease zones the entire structure will be loaded will defaults and not from the .xml file. If any zone name is changed it will also see those changes and is coded to load all new defualts and not the .xml.

With the above changes you no longer need to delete the .xml file when changes are made and program will load the structure accordingly.


Sorry but the Attachment Expired!

vining

Here's an update to the previously posted scheduler. In this version I added a new varaible to act as a queue to store strings that need to be sent to the stats and put in a new timeline to control the timing. This method is a more sensable way to handle these strings than the convoluted way I previously did it. This should also be more reliable for systems with a large number of stats as the previous method may have had issues if the time required to send all the strings with the nesecassry delay in between took over a minute to complete. That would be a lot of stats and probably more than would ever be installed but ....

RicardoSiqueira

First of all, I would like to thank Vining for all the effort he put on developing the above ViewStat Scheduler and sharing it with us. Since the ViewStats have no scheduling features, a module like Vining's is essential. Does anybody have a ViewStat scheduler module that they would be willing to share? I am trying to bring this topic to AMX attention and show them how important this is. In my opinion, for the price we pay for each thermostat, AMX should provide a self contained scheduler module that we can use for either RS-422 or ICSNet communications. I am hoping at least for AMX to take a look at Vining's Scheduler and perhaps modfy it and release it back in a self contained module. I will contact my local AMX Rep. and see if he can forward this to AMX engineering.

Any other modules?

Ricardo

RicardoSiqueira

Hello Vining,

I am having a couple of problems with the ViewStat Scheduler Module:

1)I set ? HVAC_ZONES = 2 ? , but for some reason the ? nVST_NumZonesLoaded ? is fixed on 3. The Structure ? sVST_Stat ? still loads 3 zones even though I have defined only 2.

2)The XML is not being written. All the code run fine as far as setting time and cool and heat. It also executes correctly when reaches the preset time. However, when I reboot the Master it loads only the default values. I FTP to the Master and the XML file is empty ? 0 bytes.

Any ideas? Thanks.

Ricardo

vining

Ricardo,

(*(VAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAV)*)
(*(VAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAV)*)
(*(                         ***                             )*)
(*(                   MODULE CONSTANTS                      )*)
(*( 	CONSTANT IN THIS SECTION ARE USED BY THE MODULE     )*)
(*)            WHEN THE MODULED IS COMPILED                 )*)
(*(   CHANGES TO ANY OF THESE VALUES REQUIRES THE MODULE    )*)
(*(                   TO RE-COMPILED                        )*)
(*(                         ***                             )*)
(*(VAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAV)*)
(*(VAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAV)*)
 
     VST_HOLD_REPEAT_FAST    = 100 ; //constant for timeline fast "hold repeat". 
     VST_HOLD_REPEAT_SLOW    = 400 ; //constant for timeline slow "hold repeat".
     HOLD_REPEAT_WAIT_TIME   = 50 ;  //five seconds to go from slow to fast repeating.
     
     // needed for this include file and module (original to file)
     
     HVAC_ZONES              = 3 ;   //must match number of zones (t-stats)!
                                     //must match cVST_Z_NAMES zone names array (t-stats)!

Did you recompile the module after changing the number of zones in the .axi like it says in the block comment at the top of the constants of the .axi. When the module is compiled it pulls in the values of these constants and in turn sets the size of the structure. There's not really away to change this other than setting the module to a max number say 24 zones and then passing it the actual working number of zone which in your test case would be 2. I would have done it this way if I only supplied the .tko file of the module but because I didn't I figured why allocate more memory to the structure than is actually needed.

As far as thse XML file goes the way the code is written it will only write or re-write the xml file when you exit the scheduler. My thinking was to only write or re-write once rather then everytime a zone or a period is changed. Make your changes, exit the scheduler and then ftp you master an see if the file is created. If it's not then something is messed up and I'll have to look into what that might be. You can also set the debug variable to 1, open up and enable diagnostics and go through the procedure again and see what errors or send_string 0 returns your getting.

vining

Ricardo,

Make sure you change the number of named zones here also.

(*>)VAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAV(<*)
(*>)Needs to reflect number of elements in device/SN array.(<*)  
(*>)VAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAV(<*)
(**)                                                       (**)
(*>).......!! ENTER NUMBER OF HVAC/VST STATS ZONES !!......(<*)
(**)                                                       (**)
(**)                                                       (**)
(**)volatile char cVST_Z_NAMES[HVAC_ZONES][VST_MAX_ZNAME] =(**)
(**)		   			         	   (**)
(**)		    {                                      (**)
(**)							   (**)
(**)		    {'Basement'},                          (**)
(**)		    {'Family Room'},                       (**)
(**)		    {'Office'}				   (**)
(**)		   			                   (**)
(**)		    } ;      		       		   (**)
(**)		  			              	   (**)
(**)		                                           (**)
(**)		                                           (**)
(*>(   IF ZONE NUMBERS CHANGE, ADD OR DELETE ZONES NAMES   (<*)
(*>(  AS REQUIRED AND RE-COMPILE VAV_VST_SchedulerMod_V1.  (<*)
(*>(!!CHANGING NAMES DOESN'T REQUIRES A MODULE RE-COMPILE!!(<*)
(*>(                                                       (<*)
(*>(!!CHANGING NAMES DOESN'T REQUIRES A MODULE RE-COMPILE!!(<*)
(**)                                                       (**)
(*(VAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAV)*) 
(*>)VAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAV(<*)
    

I just changed my running code to to 2 HVAC_ZONES, changed this array, saved this file and re-compiled the module and it worked fine. My thinking is it will work fine once you re-compile the module but if it doesn't, do what I said in the last post and let me know how you made out.

RicardoSiqueira

Vining,

You're right, after recompiling it worked, including the XML. My problem was that I had forgotten that the ' VAV_ViewStat_SchedulerMod_v1 ' and the ' VAV_ViewStats ' are both working as the hole module, not like a typical standalone module which the COMM module is independent from the UI module.

Again, I thank you and think that you did a great job. I am trying to contact AMX Engineering and see if they can look at your module and probably consider making it standalone and adding ICSNet support. Again, a scheduler for the ViewStats is a must. Also, I don't know if you ever seen the code that Design Xpress generates for the ViewStats. They have newer functions and handling that could probably improve your module quite a bit.

Ricardo

flcusat

Vining the zip file is not available any longer. Could you send it to me?
flcusat@bellsouth.net.

Thanks.

bjray

Can someone please send me the Viewstat scheduler module? Thanks,
Brandon
bjray@nomadgroup.com

alexsquared

need module

please send to me as well. alex@isg-group.com Thank you.

overclocker

Also would like the module

Could you please send it to lou@mediushome.com?
thanks-lou

jjames

Could someone send it to me as well?
jwjames83 (at) gmail (dot) com

Thanks!

vining

Right now it's stuck in my outbox but as soon as Outlook releases it you'll have it.

jjames

vining wrote: »

Right now it's stuck in my outbox but as soon as Outlook releases it you'll have it.

Thanks a ton!

vining

Well my outbox is still not processing the email so here's the zip file. Actually I found a newer zip file than the one I was trying to send via email so maybe its an improved version.

You'll need to use the include file and make whatever changes to it to taylor it to your system. I've supplied the .axs module which I believe needs to be compiled after changes are made to the include file. If I remember correctly the module pulls in constants from the include file to determine quantities and sizes for its arrays and structures so if you make changes to the include just play it safe and re-compile the module.

Just go through the include change the applicable sections, number zones, zone names, etc. and then re-compile the module. Add the include to your system and the include will instatiate the module. The include file is based on the original AMX version but modified and renamed and this code uses the original AMX comm file tko so make sure all this stuff is in your working directory.

The 17" has a slightly different GUI with better feedback so you might want update the other versions with its modifications.

Good luck and if you guys need any help I'll see what I can do.

The newer file didn't have some of the newer code that I used in the 17" so I pulled this code from a current working job.