kewashi

Thanks for sharing this guys. I had previously bought Z-Wave blinds from a company called Zebra blinds with good success. I have two of them and they work like a charm connected to my Hubitat Z-Wave hub, that is then tied into ISY via my Hubitat-to-ISY node server. I wanted to buy 5 more and found that they were bought out by a company called Select Blinds that switched from ZWave to WiFi protocol. https://www.selectblinds.com/roller-shades.html However, they sell a bridge called "Select Connect" that supposedly can be used to connect their WiFi blinds to Alexa, Google Home, and hopefully also ISY and/or Hubitat. https://www.selectblinds.com/blinds-select-connect-smartphone-bridge.html I have them on order and have been notified that they will arrive in a week. Once they arrive I will report back here how the integration goes. If anyone else has any experience with this company I would appreciate knowing.

So glad you have it up and running and that you like it. I've made some updates to fix music devices and a few other tweaks, and I updated the GUI portion of HousePanel to have a few more visual goodies, so if you are using it I would grab an update from the GitHub repo. Otherwise, if you are just using the node server and don't have music devices from Sonos, just keep enjoying the current node server as-is.

This is the URL that points to the HousePanel.groovy app on your Hubitat box. It will be in a format similar to below Key = hubEndpt Value = Hubitat endpt in format http://192.168.x.y/apps/api/n where "n" is an integer number, and x and y are the IP address specifics of your hub. You can find this information after you install the HousePanel.groovy file as a user app on your Hubitat box. Open up a log window and then do the installation. The app information will show in the log. Of you can find it later by just looking at the id number of the app once it is installed. You will also need to give a callback port in the install that is set in the config.

Thanks for making a new area for this node server. I'm the author and have documentation under development for this Node Server and the associated GUI at https://housepanel.net Once you get the node server up and running, and the GUI installed following instructions at the same website, here is an example of what you'll be able to make. All tiles on this page are presented to HousePanel from ISY using the Hubitat node server.

HI Folks I've been using the Hubitat node server for more than 2 months now with no issues. The stability and performance have been very good. This weekend I added support for Music tiles and Aqara presence sensors but everything else is unchanged. I updated the Beta store to include this as V1.0.9 and I added a new Production Store version 1.0.9 that you can try free for one month and $20 after that. I hope people find this useful and feedback is always welcome. Actually I ended up posting it to the Production store.

Hi @Riggins44 I don't use dockers so I'm not going to be of much help. I install apps natively on my Mac. The installation of HousePanel and the Hubitat node server on your RAID should be supported and straight forward. There is nothing fancy here so a basic Python install is all you need.

I’m documenting things at: https://housepanel.net

I'm still tweaking it and testing it, so I'll post it to prod store once it is more stable and I'm happy with it. That said, it should be stable enough now to use for most people. I have two hubs and over 150 devices so my setup is pretty complex. I just tested it installed in a second slot to support my 2nd Hubitat hub and it worked like a charm. You do have to use a separate restPort if you do that. I am tweaking the HousePanel.groovy file to support port ranges for such cases.

My Hubitat Node Server was just published to the Beta store. There is a one month free trial, or $20 perpetual license. I'll write a longer release post separately.

I was in the same boat, which is what prompted me to write this node server. It should be posted by tonight.

Hi @GPG I'm putting the finishing touches on a Hubitat node server that I've been developing for the last month. It supports just about all device types, except music for now. It uses hints to map devices to the right Hubitat types. On the Hubitat side, you have to install a groovy app called HousePanel.groovy that is the same groovy app used by the HousePanel dashboard app that has been around for a few years. You can get started now by installing that here: https://raw.githubusercontent.com/kewashi/HousePanel/master/HousePanel.groovy The discussion thread on the Hubitat forum for HousePanel is here: https://community.hubitat.com/t/housepanel-2-node-version/36049 The added benefit of using my Hubitat node server is that if you use HousePanel GUI it will read the nodes, recognize the device types properly, and control them via nice looking and fully customizable tiles on a dashboard that looks equally good on a cell phone as it does on a tablet or computer.

I'm using the example and templates in the PG3 github with no success. The node servers I install from the store work fine but when I install one from github or one that I write modeled after the example counter app, nothing works. What am I missing? For example, I installed the code here: https://github.com/UniversalDevicesInc/udi-example3-poly and it didn't work at all, which explains why my app modeled on it also doesn't work. I'm on eisy running the built in PG3x V 3.1.23

You have to install HP from GitHub and then do npm install.

I might set the Initial value of the state to 21 or 31 instead of true and false.

The rule will never fire because true is never set as a result once the panel loads the hub data. It is only set when the hub is first initialized. I think your rule should focus only on responding to 21, 31, and other numbers. You can use the initial true as a secondary logic test which just checks the existing state, but the first logic test must be something that triggers. For example: if switch=on and 342=status=true, 25=mystat=onandtrue will work if the program has never fired.

Oh boy... well, you weren't missing anything. I actually wrote a comment in the code that said "skip processing rules for programs since that seems silly". My logic at the time was if someone was using a program tile wouldn't they put the logic inside the program? What I didn't anticipate was a power user like you that wanted to set a text field or do other useful things with the powerful rule engine. Well I have now enabled it and tested it and what you are trying to do works fine. Update the main hpserver.js and utils.js files as usual to V2.417 and you will be good to go.

I looked at your log and it appears to be crashing in a console.log debug print statement with some type of buffer overflow. Please confirm you don't have any circular rules - that would cause this issue. I can't find any link between this error and the "$" feature. Will keep looking.

Hey - sorry about the delay. Yes, this is an easy change. I can just load the actual value in the status field so it shows 21, 31, or whatever for the state it is in. This field is likely only useful for a RULE and won't be displayed to the user anyway, so my original intent of translating the state to true and false need not be done. Although I should mention that the initial node state only sets the status to "true" or "false" so it will be inconsistent with the init value. I made the change and will post an update tomorrow (Sunday).

Yes - you can do what you are trying to do, but you have to use a special notation to tell the rule engine to use the "value of" the field referenced. The way you entered it, it will only run if lastRunTime is actually equal to the test "lastFinishTime" which will never be true. I'm a little puzzled why the rule always runs - that seems off. Anyway, the proper way to do this is to say: if lastRunTime==$lastFinishTime, 299=runstatus=stopped The $ sign tells the rule engine to compare the value in the lastRunTime node to the value in the lastFinishTime node instead of the text "lastFinishTime". Also, when comparing time fields you have to be a little careful because the rule engine tries to convert the date/time to the standard Unix format of seconds since 1971 to do the comparison. If that fails then the comparison will fail too. I can't remember if I did that for lastRunTime and lastFinishTime -- I know I did for clock "time" fields. I probably forgot, so let me check that. Anyway, the text comparison should still work fine for == tests. Also, you can compare to a node value in a different tile using the following @ symbol notation: if switch==@761$switch, 543=switch=toggle I put this rule into my Tile #117, which cause the light of Tile #543 to toggle state when the switch of tile #117 matches the state of tile #761. This is a real example that I just tried to confirm that it really works. I added this feature some time ago and never really publicized it.

Hey man, I'm sorry but in the process of implementing this improvement, I also introduced a bug that causes any tile that is the target of a rule to spuriously create a fixed TEXT link field. I posted a one-line bugfix that solves this problem. If you notice that some of your tiles become unresponsive, then that means this bug got to you. To fix it you first need to update the hpserver.js and utils.js files with the latest Version 2.415. Then stop the server and edit your hmoptions.cfg file. Look toward the bottom for any new entries with TEXT type that have a fixed value tied to existing fields. Then remove those. Be careful to keep the json format intact. These fields will look like: "user_b50a1644-3b0c-40af-9108-37461b4e4a93": [ [ "TEXT", "on", "switch" ] ], The bogus spurious entries are easily identified as changing important fields like "switch" as shown above. A safer but more tedious way to fix this is to restart the server and then go into the customizer for each messed up tile, and delete the spurious custom "switch" or other created fields. The tiles will look weird because the deleted field will be missing, but after you do a Refresh they will be restored to normal by reading those fields from the hub. Sorry about that, but progress comes with such issues.

Posted V2.414 Today But... First - let me say thanks for finding an important limitation in HousePanel. Turns out what you were trying to do was not supported. This was a shame because it made the RULE feature with GET and POST far less useful. Well I spent a few hours today fixing that so you can now link any RULE logic to any existing GET or POST link in another tile and the function will execute, just like when you link a RULE up to a built in feature. Here is my test case, which shows you how to use it. But basically, you use it the way I described it previously, but this time it will work. I put a GET call in the tile on the right (tile #680) that turns on a light in my house. I used the built in HP API to do this by simply calling my HP server with a GET call as follows: lampon: http://192.168.11.20:3080?api=doaction&tile=117&value=toggle In my test tile #470 I have a rule that checks for its own switch to be anything so it fires upon any change in state to call the lampon GET in tile #680. I do this by checking the value to not be a bogus "x" value. If you want to have unique triggers for "on" and "off" or "DON" and "DOF" that can be done too of course. triggerlamp: if switch!=x, 680=lampon=lampon With this setup when I turn the light on tile 470, it fires the rule which in turn fires the lampon GET call. Pretty spiffy. I took no precautions to avoid circular logic so be careful not to cause one rule to trigger itself or you will get an infinite loop with switches firing each other over and over again. The only fix to that would be to restart the server on the rPI.

Here is what you need to do. First create the custom GET item on any tile. Be sure to make two - one for on and one for off, unless you have an API call to toggle it. Let’s say you called your new custom fields: “geton” and “getoff” next make a rule that ties the DON of the switch to call the two new fields like: if switch==DON, 23=geton=geton if switch == DOF, 23=getoff=getoff assuming you added the field to tile #23 the trick is to trigger a custom field by invoking it with any parameter. I like to use the field name but I think it can be anything i haven’t tried triggering a GET or a POST from a rule but it should work. I will try one later and let you know. I do know that you can’t trigger a rule from a rule. Edit: Per post below, this previously didn't work, but now it does after V2.414

Turns out I had goofed up the GET customize feature. I fixed it today, so you will now see a GET option in the customize dialog box. Use that instead of POST or URL. Then simply paste the above line into the value box on the right. Any result returned will show up in the tile. You can suppress this by using a custom field name that starts with an underscore. Here is an example I used to test this. This calls the Harmony API on my local network. Notice the _getstatus starts returns all fields but they are suppressed because of the underscore. the testget on the other hand returned the name of my hub and stuck it in the tile. A screen refresh is required on the first press for this to work. Regarding my rework, it should be ready before the New Year. It is a precursor to me making a Polyglot version. I simply had to switch to using a database for the Polyglot idea to work. It was also needed to enable easier installs for SmartThings users and to use the new Hub calls. Long story but I will say more later.

Hey man ... I’m good. Just busy working on a full rewrite of HousePanel to use a database instead of flat file reads. It will be tons better but it’s a lot of work. Stay tuned. in the meantime try using a GET custom command in the customizer. Should work like URL but without the browser page open. if you send me docs I can look into adding native support. Merry Christmas

You are right - the levels are not acting quite right. I am still investigating. It doesn't happen all the time so finding this issue isn't easy.