WebSocket port needs to be a valid non zero port. I use 1337.
Set it in auth page.
I got it working... I had a 0 in the WebSocket port... changed it to 1337 and re-installed everything... It has broken at least once and I had to re-start the service, but so far so good...
What are the best settings for the timers... How does that play into this? I've been changing the numbers but I don't know what they represent in terms of time and what the optimal settings should be...
Also, when I hit the info page @:19234, it doesn't show connected clients... I am showing the service running and getting the last 30 activities though...
A new bug I just saw is when I turn a device on or off, the tile name switches back to the original device name... It will stay that way for a bit then go back to my edited name... Just noticed it as I was messing with the Node stuff... Could have been from the changes I'm making in the timers? Or something you changed a few days ago?
The timers are in microseconds and are used as a backup to the push change. They tell HP how often to poll so that if push fails you still get updates every so often. I leave these set to 60000 which is once every 60 seconds.
That is very strange. You might try closing your browser and then opening HP again fresh. It should connect to the server upon launch as long as the port is set to 19234
By the way, if found a really great rPI resource online that could help you configure your rPI to an optimal state:
For both?
I'll keep playing with the Node stuff... How about the tile header changing? Any ideas?
There are actually three timers.
Fast Timer - used to update frames and blanks.
Slow Timer - used to update things that don't change often, like weather
Refresh Timer - one for each hub, is the poll refresh timer described in my prior post
For Fast timer I would leave it at 10000 for every 10 seconds
Slow timer can be anything big such as 360000 which is once an hour
and Refresh timer 60000 for once a minute poll
To give your hub a break, you could set Fast Timer to 60000
sounds like a bug... let me explore
Yeah, the header thing is intermitent and seems to come and go as I have been playing with these timers... If that helps...
Can you help me understand something... And I appreciate all the help you have given...
I don't understand the whole polling/refresh thing... I've messed with that in the polling app and rule machine...
Does HP do some of that? Do I need polling/refresh going since I'm running HP?
Just wondering if that was messing with Node? I've had it all off and Node working. As soon as I tried to configure some polling, Node broke...
They should work independently of each other. Polling just makes a call to the hub to get the states of all things in HP. It then updates the screen. Polling speed is limited to about once every 30 seconds so the direct hubpush method is much better at giving an immediate update. Having both is good as a backup.
Minor update to 2.049 tonight includes Version number added to main screen, and a bugfix to the digital clock that always reported the time in the local timezone instead of using the user provided time zone in the settings option. Now it uses the user settings for timezone to update the real time clock every second. Note that the analog clock still only shows the time in the local browser time zone. This is unchangeable because I use a plugin that has this hard wired.
Thanks for the update. I have everything pretty stable with the Node.js app running well... I do see the problem with the titles changes consistently though... It has something to do with the new way the tile changes for a second in between modes. Somehow, that is letting the device name override the tile name... It stays that way for a few seconds and as much as a few minutes before switching back to the tile name.
Glad you have things stable. I'm just not seeing this behavior so it is hard to troubleshoot. Which one is overwriting which - header over name or name over header?
[EDIT] Here is a simple demo. This is a Custom tile where I changed the background image to an Actress photo and changed the name to the Actress name. Saved it and checked the hmoptions.cfg file and it had the name in the setup. All looks normal and it didn't overwrite the name with the old name. Perhaps you don't have the hmoptions.cfg file as writeable?
[EDIT]Well crap!!! I spoke too soon. Sure enough about two minutes later the name changed back to Custom 6. Okay, at least now I have something to work with to find the bug.
I can send screen shots or logs if you need them too... 
And, the hmoptions is writable if it matters...
Okay - I know the cause of the error but I can't get it to happen repeatedly. The cause is the name doesn't stick when your user-specific cfg file doesn't get a copy of the custom name settings. Let me explain.
Let's say you created a user called "upperman" then HP will create a file called hm_upperman.cfg and copy the room configuration section of hmoptions.cfg to this file. Every time you make an update to a tile that update gets saved in both hmoptions.cfg and hm_upperman.cfg as long as you are logged in. That means a custom tile location and a custom tile name only applies to that user's panel. This is a design feature because some users will want tiles in different places and will want special names. However, I every once in a while when a user name is created, the custom name is not saved in the user specific cfg file. I have stared and stared at this and can't figure out why. A few things I know will make this barf is if your hm_upperman.cfg file is not writeable. That needs to be set just like hmoptions.cfg as writeable by the web browser. chmod 777 is the simplest answer but a safer approach is to set the user to www-data. Mine was set properly and it still happened but only once and I can't make it happen again. Another thing that will make it barf is if your browser doesn't store cookies. The user name is saved in a cookie and that is needed to tell HP which user file to update when hmoptions.cfg is updated. This is done in the main hmoptions.cfg write function so it should always happen - but again, only if the cookie is set. I know this is a lot of developer insider mumbo jumbo but I felt I should explain as much as I know. I will keep looking at it and report back later. I think it may have something to do with multiple clients stepping on each other. More to come.
Minor update to fix bugs - Version 2.050 posted.
This fixes the name clobbering mentioned in the prior post. Thanks to @SuperDupe for pointing this out.
Also added a timezone to the groovy file so events report out in your preferred zone. This is separate from the timezone in the main app which governs clocks.
Finally, this update enables Hubitat events to be included and enables flashing lights in Hubitat. Actually with this update any command presented by the Hub for a dimmer or bulb will be exposed and enabled. I know Hubitat exposes a _flash function so this is supported.
After applying this morning's updates, I'm still seeing the tile title changes... 
Nothing appears to have changed on my end... All my .cfg have the right permissions... In the skin-housepanel folder I see you updated the housepanel.css file. Does that need to be updated in the other theme folders? I'm using the skin-modern theme...
The css change was only to support flash commands - I will add this in the next update but it shouldn't impact the issue you are having.
With this update I was not able to replicate the error. I am stumped as to why you are seeing the names continue to change. Can you try to edit one tile and save it and see if that sticks?
Yes, I'm able to make changes... I'm watching the cfg files and they both updated... here are screen shots... the switch is on, i turn it off and the name flips... about 30 seconds later it goes back to what i have named it...
OH!!! Thanks for sharing this. I thought it was sticking with the wrong name. Now I know where to look. The old name is likely being returned by the hub query. Stay tuned. By the way, I cleaned up the modern/housepanel.css file to include flash and other corrections so I will post that later tonight too.
Cool... Thank you!
Updated the modern/housepanel.css file and the housepanel.js file to try once again to fix the name clobber bug. I can't see this on my system because I am doing remote dev work so full testing is at the mercy of gracious users like you @SuperDupe Thanks so much!
To upgrade to this version all you need is to replace housepanel.js, skin-modern/housepanel.css, and housepanel.php files and reload browser
