| Author |
|
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 02 2020 at 21:13 | IP Logged
|
|
|
Just in time for the holiday....the public beta of PowerHome version 2.2 beta3 is now available for download here:
PowerHome 2.2beta3 Install
After doing the full install above, unzip the following patch file into the PowerHome directory and overwrite existing files
to upgrade to version 2.2 beta3-5: PowerHome 2.2beta3-5 patch. You'll need to run the
PHUPG.EXE database upgrade utility as the database has changed.
Lot of new controllers, plugins, and features. Help file has had alot of updates as well. You can also view the help file on
the web here:
PowerHome Online Help
The private beta testing went very well and it appears all major bugs have been worked out. Let me know if you encounter any
problems,
notice
any missing features, or find any errors or deficiencies in the help file.
Happy 4th of July!
Dave.
Edited by dhoward - August 27 2023 at 13:18
|
| Back to Top |
|
| |
Jerrem
Newbie
Joined: December 23 2008
Location: United States
Online Status: Offline
Posts: 16
|
| Posted: July 04 2020 at 18:55 | IP Logged
|
|
|
Dave:
This is great! Love the additional controller support
and updated manual. It has convinced me that it is time
to update my Windows XP, Powerhome 2.1.4 machine.
One thing to check is in the manual section for
Insteon/Insteon Explorer/Links,Manual Linking and KPL
Config, these pages point to PowerHome Formula
Functions(left, Log, Logten).
Thanks again for all the upgrades!
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 04 2020 at 23:34 | IP Logged
|
|
|
Jerrem,
Thanks for that catch! I just checked the help file itself and it looked fine but the web based help is definitely corrupted. I'll work on getting
that fixed.
If you find anything else, let me know  .
Dave.
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: July 05 2020 at 13:53 | IP Logged
|
|
|
Hi Dave!
Amazing work on beta-3! Wow. You’ve been busy.
Fantastic job! 
Thank you.
Because of your work, I am now motivated to update my PH app for my new house here in Las Vegas. I started with my app from Phoenix
and I am updating it for my new house. I have changed my hardware and now I am having problems.
The whole series of problems start with the fact that my Drive-C is now an M.2 SSD. As was discussed before, scrubbing an SSD
with constant database hits will diminish the life of the SSD. To add more pain to this issue, my video system outputs a snapshot
of 15 cameras every 5 seconds. That’s a lot of writing. So, I had the idea of writing those images to a RAM disk where PH is running.
Well, that exposed a series of problems with PH. So, I tried putting the images on a hard drive (not drive-C) and I had different
but significant problems.
These issues were not a problem before because I had a hard Drive-C in my previous system.
I show the video snapshots in my RCC for the various rooms and places. I would prefer to not lose this capability.
I would welcome your thoughts.
I have PH 2.2 beta-3 installed on Drive-C, fully copied to RAM Drive-E, .ini configured to point to RAM the database on Drive-E...
so far so good.
The server is PH 2.2 beta-3 System:
M.2 SSD Drive-C
RAM Drive-E
HARD Drive-F
Define:
CC:..............Control Center in PH
Local RCC:....RCC running on the PH server
Remote RCC..RCC running on a separate remote PH 2.2 beta-3 system
Pretty much, graphics must be located on Drive-C, otherwise there are inconsistent results.
Here’s how I tested this:
(This is complicated, so go slow)
1. On any convenient CC page
A Create a STATIC GRAPHIC in CC using design tool, get graphic from Drive-C and set a border.
For example: c:\powerhome\web\graphics\buttons\b1blue-d_50.gif
Graphic and border shows on CC, Local RCC and remote RCC. All good.
B EDIT using design tool to change graphic from hard disk Drive-F
For example: f:\powerhome\web\graphics\buttons\b1blue-d_50.gif
Graphic does not show on CC or Local RCC or remote RCC. Border DOES show on CC, local RCC and remote RCC. Not good
C Change graphic back to Drive-C and graphic and border returns on CC, local RCC and remote RCC. All good
D Using design tool, change graphic to come from RAM DISK Drive-e:
For example: e:\powerhome\web\graphics\buttons\b1blue-d_50.gif
Graphic and border show on CC, local RCC. No graphic on remote RCC but border does show on remote RCC. Not good
2. If Graphic Type is changed to ACTION GRAPHIC, same results with the added functionality that the ACTION always functions on the CC,
local RCC and remote RCC, even if the graphic or border doesn’t show (as described above).
3. If graphic type is changed to GRAPHIC BUTTON, there are significantly different results.
If the graphic comes from Drive-C, the graphic shows on CC with border. The graphic also shows on the local RCC and remote
but no border.
If the graphic comes from hard Drive-F, the graphic doesn’t show on the CC but the border does.
The graphic does not show on local RCC and also not on the remote RCC and no border also.
If the graphic comes from RAM Drive-E, the graphic shows on the CC with border, shows on the local RCC with no border.
The graphic doesn’t show on the remote RCC and no border but it still functions.
I'm thinking that his is an old problem and NOT related to any betas.
I seem to remember that I had issues like this before, but I could not define them.
I'm open to your thoughts.
Thanks, and thank you again for all your work!
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 05 2020 at 20:43 | IP Logged
|
|
|
gg,
Read through the post and not sure if I understand the problem completely. Whatever the issue is, it's likely a problem that has been there since
nothing really changed on the Control Center side of things.
Completely understand about the SSD drive. Definitely don't want alot of repeated write activity burning through the limited number of write cycles
(read of course is no problem). As such, if it were me, I would install and run PowerHome from the C: drive. I would have the pwrhome.ini file in
c:\powerhome (the write activity to this file is almost nothing. Once PowerHome is configured, unless you're opening a bunch of windows and
moving/resizing them within PowerHome, nothing should really be written to the INI file). The pwrhome.db and phlogs.db files I would of course put
on either the E: drive or the F: drive. I would probably just do the F: drive so I don't have to worry about read and saving the files at the end of
the day. Your graphics should be able to just stay on the C: drive in c:\powerhome\web or you could also move that whole directory to the F: drive
as well but no writes should be taking place there.
With that arrangement, you've got PowerHome on the fast SSD so it can launch quickly as well as access the graphics quickly. Database operations
will all take place at normal speed since they would be on the hard drive. In your pwrhome.ini file you would just need to update the database and
logs entries to point to f:\powerhome\database\?. If you did locate the graphics to the F: drive as well, then also make sure that you update the
webserver directory in the INI file to point to f:\powerhome\web.
With this setup. The PowerHome internal CC should work no matter what. For the Remote CC's, you'll need to configure the phremotecc.ini file
properly. Now one thing you do want to do is make sure that all your graphic files for the CC are under the same common directory structure
including your camera images. In my examples below, Im going to assume your graphic files start at f:\powerhome\web\graphics and you are placing
your camera images in a subdirectory underneath f:\powerhome\web\graphics. For the Remote CC on the PH machine, you'll want to set the
removepath=f:\powerhome\web\ and the addpath=f:\powerhome\web\. When you build your CC screens, make sure that you select the graphic files from the
f: location. With these settings, both the internal CC and Remote CC on the PH machine should just work.
For the Remote CC on other machines, you've got a couple of choices. You can copy all the graphic files on f:\powerhome\web\graphics to the Remote
CC hard drive (preserve the directory structure). If you put those graphic files on the remote CC machine at c:\powerhome\web\graphics then you
would configure the remote machines phremotecc.ini removepath=f:\powerhome\web\ and the addpath=c:\powerhome\web\. The problem with this is that the
camera images are not going to work because they're going to be copied to the F: drive of the PowerHome machine. To get the camera images accessible
by all machines, they'll need to exist on a shared drive somewhere. Since the Remote CC clients don't receive the graphic files over TCP or UDP like
they receive the CC information, that would be the only option that I can think of. Static graphic files can of course be copied to each machine
that needs them and the removepath/addpath will make everything match up but the dynamic images would need to be in a centrally accessible location.
The key is that ALL machines including the PH machine and remote CC machines would have a drive mapped to the same letter. If the PH machine maps
the images as g:\powerhome\web\graphics\camera then all the remote CC's need to as well.
There is more I can go on about configuration but I don't want to get too far ahead of ourselves. Let me know if what Ive said makes any sense or is
applicable to your environment. Im pretty sure we can get it all worked out for you.
Dave.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 05 2020 at 21:04 | IP Logged
|
|
|
Jerrem,
The problem with the online help should now be fixed. I recompiled the project and FTP'ed the new files and the Insteon entries are now all working
properly. Hopefully something didn't break somewhere else .
Thanks for catching this.
Dave.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 06 2020 at 09:58 | IP Logged
|
|
|
All,
One other thing that came out late in private beta testing was the option to supply a "refresh" parameter for web based Control Centers.
You can make use of this by adding "&refresh=10" to the end of any web Control Center URL. The "10" is how often in seconds you would like
for the web page to check PowerHome for changes that have occurred to that CC page. If a change is detected, then the CC page will refresh
itself.
This isnt as nice as the Device Status screen with the background auto refresh but best I could do on short notice since Control Center
changes arent actually tracked with a date and time like Device Status changes. The original request was to have the CC refresh
automatically at a fixed rate even if changes did not occur so I think this is a good compromise.
I will be looking at other options to refresh both the Device Status and Control Center web pages automatically in near real-time.
Dave.
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: July 06 2020 at 16:40 | IP Logged
|
|
|
Hi Dave,
PROBLEM SOLVED! Thank you!
The key was when you said:
"The key is that ALL machines including the PH machine and remote CC machines have drives mapped to the same letter."
That was what I was missing. With that, all is working nicely. I thought that the images were sent to the RCC but since they are not,
mapping the drives to the same letter drive on the server was what I was missing.
Also:
"&refresh=10" to the end of any web Control Center URL is AWESOME!
I can't thank you enough.
Thank you.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: July 06 2020 at 19:47 | IP Logged
|
|
|
Hi Dave - just looking at the manual I can see you've done a lot of
work. Awesome! And honestly, only with you as the author would
I take "rewritten for greater stability" at face value :-). Couple of
qns?
1) Is there additional support for motion sensors, closure sensors,
etc? Right now I have to call them all Controllincs :-)
2) For the functions that changed, are they backward-compatible?
For the deprecated ones, what's the easiest way to figure out
where I need to rewrite my code?
Thanks!
/j
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 06 2020 at 23:26 | IP Logged
|
|
|
gg,
Glad to hear you got the problem solved. I knew if I kept rambling I might actually get something of use across .
Thinking of this conversation, Ive also gone ahead and added a command line option so that you can specify the location of the
PowerHome INI file as well. This will allow you to completely relocate the "updateable" content to somewhere other than where
PowerHome itself is running from.
Dave.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 06 2020 at 23:46 | IP Logged
|
|
|
Jeff,
Not alot changed with Insteon in terms of features. There is now support for FanLinc devices through the Analog IO screen. But additional
Insteon device types have always been able to be added using the "Types" tab in the Insteon Explorer. The easiest way to do this is to set
the "Device Type" column in the Devices tab of Insteon Explorer for the device in question to "* AutoDetect Type *". This will cause
PowerHome to query the device for details and if a match based upon Category and Sub Category is not found, it will create the device for you
in the Types tab (you'll need to Save/Refresh to see the new entry) with as much information that can be obtained already filled out. You can
then give it an appropriate name and tune any of the other parameters.
If you've been using Insteon with PowerHome for quite awhile, additional Device Types have been added through the various versions. If you
were starting fresh, these would be in your database. If you always upgraded (which is definitely the path people should take) they would not
get the new device types added to their database.
In the new 2.2beta3, in the "database" directory, I have included a basetable_update.sql file. You can open this in notepad and scan for
entries that may have been missed in your system that you can add. Im looking at the file now and there is a whole section on INSTEONTYPES
and it does include entries for Motion sensors and TriggerLincs. You can get these into your system by copy/pasting the whole INSTEONTYPES
section into the PowerHome Multi-Editor and execute it in SQL mode (Shift+F5). Don't worry about picking and choosing. The SQL is written
such that it will only add missing entries.
Concerning the deprecated functions, it's unlikely that you actually used any of them (they werent common which is why they were removed) but
it would be easy enough to check. Under the menu item Reports select "Database where used". In the popup window enter "%ph_getother%"
(without the quotes) and hit "Go". You'll get back a list of everywhere you may have used this text in your PowerHome database. That will
take care of searching for 6 of the functions. Change the search to "%ph_setother%" and you'll cover another 5. You can then search for the
remaining 3 one at a time in the same manner.
The functions that changed are backwards compatible. You'll see multiple syntax options where applicable where you can continue using the
older syntax or switch to the newer syntax for the ability to take care of the newer features.
If you do find that you're using a deprecated function, let me know which one and what controller and device type and I can explain how you
code for it now. Most of them are covered by an existing function such as ph_getanalog or ph_setanalogout.
Dave.
|
| Back to Top |
|
| |
jeffw_00
Super User
Joined: June 30 2007
Online Status: Offline
Posts: 929
|
| Posted: July 07 2020 at 08:09 | IP Logged
|
|
|
Many Thanks Dave - will get to all of this. I wasn't so worried about
the deprecated ones as the changed ones. - Sounds good -Thanks!
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: July 07 2020 at 14:31 | IP Logged
|
|
|
H Dave,
I might have found something with &refresh=10 on the WEB url. While it gets triggered if I trigger a macro
and update a static graphic, it does not seem to trigger if FILEMON gets triggered.
I found this because if I "operate" something in my CC or RCC the WEB page updates beautifully, but if my
camera images update, they do not update on the WEB page but they DO get updated on the CC and RCC. This
leads me to think that FILEMON doesn't trigger this new fantastic feature.
I also found that if I change the WEBSERVERDIRECTORY=c:\powerhome\web to any other structure, it breaks
this feature. WEBSERVERDIRECTORY=e:\powerhome\web works, but WEBSERVERDIRECTORY=e:\powerhome\cam\pictures
breaks this feature.
Because of the way you implemented it: that it only updates if there is a change, it may depreciate the
need for the RCC.
Also, since it only gets triggered if there is an update/change, please help me understand why I would want
to use a delay greater than 1 or 0.
Thanks,
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 07 2020 at 15:44 | IP Logged
|
|
|
gg,
It would depend upon how the camera images are being updated. The way the current code works, when a CC page is requested, a SQL request is
generated on the Control Center details table (ccbuttonstemp) and that data is used to construct the CC page. At the same time, that returned
data result has a checksum performed and that is also sent as part of the web page data. With the refresh parameter set, when the time is
expired, an AJAX call to the webserver is made in the background that requests the current checksum for the CC. When the webserver receives
this call, it executes the same SQL statement for the CC page and checksums the resulting data. This checksum is returned to the AJAX call and
compared to the checksum that was originally sent when the CC page was requested. If the same, the refresh timer is reset and process repeats.
If the checksum doesnt match, that means "something" in the SQL result data changed so the background script requests a refresh of the CC page.
What this means is that the unless the actual CC data changes in a PowerHome table, the checksum won't change. The current mechanism is in no
way tied to File Monitor or even any of the ph_setcc functions. It strictly goes against the data in the table (a ph_setcc function will make a
change to the data in the table so will ultimately result in a checksum change). Unless the FILEMON operation updates the data in the CC table,
the check sum won't change.
Im not sure how your camera images are done. If they are static graphic CC objects with a filename that is fixed and the camera updates the
image with the exact same name, then you're not changing the data in the CC table. The graphic file itself is different but it has the same
path and filename so from a PowerHome perspective, the CC data did not change. Now if you're doing something like a ph_setccobjgraphic and
actually updating the CC table with a new path/filename, then this is a change to the data and should result in a different checksum triggering
a refresh of the page.
If you are updating a camera image by overwriting the previous file (same filename) and have control to execute a PowerHome function (I assume
you may be using the File Monitor plugin) then I would put a non-visible static text object on your CC tab and do a ph_setccobjtext function on
it to update it to the current time or a random number at the same time you update the camera image. This non-visible static text field being
updated will result in a different checksum which will trigger a refresh of the page.
Not sure what you mean by changing the WEBSERVERDIRECTORY breaks the refresh feature. Changing the webserverdirectory with actually adjusting
all the files and graphics beneath it would probably break pretty much everything webserver related. This is because all the HTML is generated
as relative paths (HTML can't directly access a file on a hard drive). When you declare Control Center graphics, you are specifying a full path
and filename. When the webserver is running, it tries to create a relative path to a resource based upon the webserverdirectory and the full
path/filename of the resource. If you changed the WSD from c:\powerhome\web to c:\powerhome\cam\pictures, you completely wiped out all access
to anything in c:\powerhome\web and the subdirectories below because that path is no longer relative to c:\powerhome\cam\pictures unless you do
something like ..\..\web which is NOT allowed in webservers.
Concerning the refresh delay. A refresh=0 is the same as not specifying the parameter at all so you would get no refreshes. Setting to 1 or
some other low value will work but that means that every second (or how often you set the parameter) you'll be making a call to the webserver
to pull data and a checksum for every CC webpage that may be open. That can potentially be alot of traffic to the webserver and may slow other
PowerHome processing down. If we're talking a single instance of a CC page on the web, then you would get 1 hit per second on your webserver
which may be acceptable for you. Open the PowerHome Status window and try it and see if operations back up at all. The key to remember is that
the refresh parameter basically enables Javascript code in the browser that makes it repeatedly go out and request data from the webserver.
Hope this helps clarify things,
Dave.
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: July 07 2020 at 17:37 | IP Logged
|
|
|
Dave,
Took me a few minutes to digest that.
It makes perfect sense. The way that the camera systems works is it overlays the same file with
the same name, so there's no way that the checksum would be changed.
Knowing how the system works now, I'll do something like: when my macro triggers on FILEMON I'll
display the time in a black font off the page, or something like that, whatever works; now that I
know what's happening, I can work with it.
As to the directory structure, that also makes sense. I don't need to change it, but when I did
it stopped working. I put it all back  .
As to the refresh rate, again, it makes sense that the client has to make a request back to the
server. That's the way the WEB works. I should have thought of that.
Thank you for the explanation. I understand it, and I can work with it.
It's awesome!
Thank you Dave
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: July 09 2020 at 15:11 | IP Logged
|
|
|
Hi Dave,
I might have another issue. This is probably not new.
I run my WEB server on a different port because my ISP blocks inbound port 80. They do this so you can't run a WEB
server with a residential account. So, I use port 91. My config is:
[Web Center]
home=http://192.168.xx.xx:91/ph-cgi/main
state=0
x=0
y=0
width=6085
height=3320
This works remotely, but the WEB client in PH has a problem when the port isn't 80.
If I select "YES" it works.
Secondly I would like your input on the different WEB servers. Because of your new changes, what do these parameters do
now? Which server type is best?
WEBSERVERTYPE=0
WEBSERVEROPTIONS=0
Thanks.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 09 2020 at 16:35 | IP Logged
|
|
|
gg,
I almost never use the Web client but I set it up and tested it out. It's not an issue with the port (I run my own server on port 8000). The problem is
the new default Device Status screen (and the Control Center if you have refresh>0). The problem is due to the JQuery Javascript library that is included
in the default Device Status and Control Center with refresh. This is happening because the Web Client is using the ancient Microsoft Web Browser activeX
control which is just not compatible with modern web coding.
The good news though is I plan to upgrade to a new Chromium based web browser control that is included with PowerBuilder 2019 (current beta is in version
2017). I havent actually had a chance to look at this control yet but my understanding is that this should provide the same functionality that the
Microsoft control has.
You can get back to the older version of the Device Status screen by using /ph-cgi/main?layout=1. This uses the old refresh mechanism that does not have
an issue. If you also set the Control Center refresh to 0, then that shouldnt have an issue either.
Concerning the webserver types and options. For now you're best sticking with 0 and 0. Webserver type 0 is the original webserver code that uses a
Catalyst Socket control as the driving mechanism. Type 1 uses a newer Catalyst Internet Server control. Nearly the same as the Catalyst socket control
only the Internet Server control tracks the individual socket requests vs PowerHome doing it in type 0. Type 2 is a new Internet Server control that I
developed in C#. Very similar to the Catalyst Internet server but no licensing requirements and I can tune it for use in PowerHome. It currently has a
problem in the current beta that I believe I have since fixed and will be available in the patch that is coming soon.
The webserver options is a flags based parameter (add the desired values together) that controls some of the internal workings. A value of 1 tells the
webserver that it is expecting the client to close a socket when complete vs the default of the server closing the socket when complete. For an HTTP
server, you don't want to use an option with 1 (I'll likely remove this...it was mostly a debugging option). An option value of 2 tells the server that
sockets can remain open for an infinite amount of time vs the default of closing sockets automatically when a certain amount of time of no activity (10
seconds) has elapsed. You generally don't want to do this either and it's best to have the server auto close sockets that appear hung (another debugging
option).
Hope this helps,
Dave.
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: July 09 2020 at 21:10 | IP Logged
|
|
|
Dave,
I agree with you. I rarely use the WEB client also, but I sometimes use it to verify a CC page because
sometimes fields don't align perfectly. Most of the time I just use another browser. I was
testing/implementing the &refresh10 thing and other things, and I just thought to alert you about the issue. I
rarely locally use PH. I use PH remotely 99.99999% of the time.
You know, you might want to do a poll on this and maybe not spend precious time fixing it. Maybe others use a
browser also. A poll might be useful here.
Thank you for the update on the WEB server types. With the changes, I just wanted to keep updated.
As always,
Thank you!
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 11 2020 at 14:23 | IP Logged
|
|
|
All,
Ive updated my original post above and included the link to download the PowerHome version 2.2beta3-1 patch file. Just download this file and
unzip it into the PowerHome directory (default c:\powerhome) and overwrite existing files.
The fixes in this patch are:
Fixed bug preventing navigation to some children from the parent child button in PH Explorer
Added addtional right-click popup menu options to PH Explorer treeview
Corrected some issues with PH SocketServer control
Corrected issue with web based Control Center change detection hash function
Added button animations for web based Control Center
Rewrote web based Control Center to remove obsolete functionality and simplify the code
Added the start of "keep-alive" technology (experimental) to the PowerHome webserver (option 1)
Corrected an issue with the MQTT controller where not all topics would be subscribed properly on startup
Corrected issue with ph_setzwavedisplay not updating the zwavedevice table
Added new pwrhome.exe commandline option (-ini) to specify an alternate path and file for the pwrhome.ini file
Let me know how it goes.
Dave.
|
| Back to Top |
|
| |
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: July 11 2020 at 17:07 | IP Logged
|
|
|
Dave,
You can't do that! 
You can't say "Added button animations for web based Control Center" and NOT explain that!
While you're at it, can you identify the syntax for command line option (-ini)?
Thank you. 
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: PowerHome 2.2 Public Beta now available
