Did I miss something Samsung said, or are you inferring that based on their actions?
Replace your partition DTH with the code linked in the post below. Itâs still a work in progress, but it works.
Much of the recent conversation between @steinauf, @ruinertt and others has been about STHM integration. They have posted solutions, but youâll need to set up virtual switches and use webcore. If you have trouble following what theyâve laid out as the solution, post questions and Iâm sure youâll get some help.
I thought that part of the thread was trying to get your system to recognize your 2nd partition.
Iâve STHM functioning with 3 switches and 6 automationâs. And I may be missing something, but the newer DH still requires similar âassistanceâ to bring about sync between the devices. The process requires a lot of things to go right, in the right sequence and at the right time. A lot of serial dependencies on a on a communication thread.
The STHM replacement is where there may be hope, but if Samsung continues to successfully restrict the functionality we are trying to use, sadly itâs a dead end.
Ha,
Only on their actions.
Hi Dave, I realize this is going back 2 years, but I see you are still active. I have exactly your setup - Honeywell Vista 15p + EVL 4 + QNAP Container / Docker image. Just applied your Bridge suggestion
I saw you comment that you were âusing a QNAP NAS with a Docker node.js image via ContainerStation. It was actually pretty easy to set this upâ and that you got everything to work. I have a QNAP 451Be and have put a lot of hours into it over several days with no success. (I have read every tutorial and watched every video I can find.) I installed various versions of node.js, in Container Station GUI that run but how do I get the smartthings-nodeproxy to run. I have tried different âVolume from Hostsâ and âMount Pointsâ, (there are no suggestions on Command or Entry Point). I have placed my smartthings-nodeproxy files in various folders, but I am stuck at what to do next. Tried NPM through Terminal tab with various paths but it does not find package.json; and NPM has errors when initiated through SSH (path problem?). I have edited my config.json and package.json and checked them through JSONmate (not sure if it matters that I left other scripts in package.json besides Envisalink). Any guidance on how you set this up and your steps would be appreciated.
Hi Bill. It was awhile back so the details are a bit fuzzy and my NAS was a TS-453mini so not sure if that made any difference, but here were the rough steps I think I followed:
- Searched Container Station for the node.js Docker image and created that. Itâs essentially a linux instance with node.js pre-installed. I think I just went with the default to create it first and then changed settings afterwards.
- Used terminal to go into that instance, and ran the commands in the first post for setting up smartthings-nodeproxy after step 5. So this includes downloading the files to a location on your NAS that the instance has visibility into. For me I mapped the instance on
The unique elements are definitely with QNAP Container setup.
- In Advanced Settings â Shared Folders, I mapped â/smartthings-nodeproxyâ to my specific QNAP volume that had the node proxy folder. (e.g. /share/VOLUMENAME/smartthings-nodeproxy) as Read / Write. This is how you get access to that particular folder on the container itself.
- Network was Bridge mode with Static IP as mentioned in my earlier post
- In the Container Station instance, I actually have a script that goes and makes sure that nodeproxy is running even after a startup. I think by default it manually needed to be started. So for my case, in my Settings I set the entrypoint to â/smartthings-nodeproxy/stnpService startâ (my script) and command to ânodeâ
The start script contained
#!/bin/sh#/etc/init.d/stnpService
export PATH=$PATH:/usr/bin:/usr/local/bin
export NODE_PATH=$NODE_PATH:/usr/lib/node_modules:/usr/local/lib/node_modulescase â$1â in
start)
exec forever --sourceDir=/smartthings-nodeproxy -p /smartthings-nodeproxy server.js
;;
stop)
exec forever stop --sourceDir=/smartthings-nodeproxy server.js
;;
*)
echo âUsage: /etc/init.d/stnpService {start|stop}â
exit 1
;;
esac
exit 0
Once all that is setup and working, you may just want to create an image to keep it handy to spin it up later more easily. Hope that helps ya!
Thanks for the help Dave. Got it working. Started from scratch. Deleted shared folders and containers. Rebuilt them (I agree that it is fairly easy in hindsight)- I had been using NAT and had a port in use conflict; the Bridge mode recommendation solved. I had an Envisalink error and that was likely due to the fact I had another device (a Hubitat native application) that had been accessing the TPI port 4025 on the Envisalnk. I had disabled that application, but this time I physically disconnected it and rebooted my Envisalink. I think the reboot was the key for that issue. Thanks for the start script.
awhile ago I have my raspberry pi mess up and so the integration was not working for awhile. Then maybe a month ago, I was transitioned to the new smartthings app. So, i figured i would get this back running on my raspberry pi for smartthings integration. However, it does not seem to be working in the smartthings app.
On the raspberry pi, i have cmd running and it is telling me the correct status of my system, but i cant seem to change it in smartthings. within smartthings app, i can click arm (stay) or disarm in my home monitor section of the app, but it doesnt actually do anything to my alarm system. Is there any new configurations for this to work on the new smartthings app?
STHM in the new app is completely separate from SHM in the old app. ST is no longer allowing smartapps to integrate directly with SHM. The workaround now is to use an automation, virtual switches, and webcore to make that work.
Are your sensors and reporting correctly in the new app? For the partition, use the code below for your DTH to get it to show.
is that github updated code the virtual switch and webcore method you are talking about or is there a tutorial for that? can you still monitor each device (motion and door contacts) with this or is it now only to arm and disarm the system?
github code is the updated Device Handler that works with the new app. webcore/virtual switch discussion is there if you scroll back in this thread, itâs not that far. read on from Aug 19th and later.
thereâs a way to do it with 3 virtual switches, and with 2. doesnât matter which you use, itâs personal preference.
I am sorry I am so confused. In my ST account for device handlers, i still have all the:
[redloro-smartthings : Honeywell Partition]
[redloro-smartthings : Honeywell Partition]
[redloro-smartthings : Honeywell Zone Contact]
[redloro-smartthings : Honeywell Zone Motion]
[redloro-smartthings : Honeywell Zone Smoke]
Am i changing one of these with the new code or am I adding another new device handler? I cant find or follow what to do for virtual switches. I looked back in the discussion and see very confusing things about doing stuff with switches but i dont know how i am supposed to even get switches with this new code.
Got mine all up and running. Set my Raspberry Pi, Envisalink to static IPs so if the router resets you donât have to reconfigure the code or anything.
Question - what is the issue with it not working with the new SmartThings app? I understand classic is going away⊠and therefore possibly this integration⊠Is the new SmartThings app lacking capabilities?
The new app in its initial version did not allow for custom capability or UI in devices. So no custom UI, no custom buttons to arm away, arm stay, etc.
That custom UI featureset is in beta and you can see the initial results in what @philh30 posted above. Its rough for now but as Lafayette said in Hamilton⊠Gets the job doneâŠ
Where are you getting the 2nd Honeywell partition? How did you add it? The â2ndâ partition for me is the one that @philh30 created as you can see below (itâs the first one with the expanded capabilities):
1 Like
General question on credit for coding, since Iâm not sure what the etiquette is. Should @philh30âs DH update the namespace to his own name? Not to take credit away from @redloro, but to help reduce confusion?
Or perhaps change the name of the DH to âHoneywell New Partitionâ?
Youâll need to thoroughly read the posts I linked to, as well as some of the posts from before and after. A lot of this has been explained recently.
For virtual switches, this should guide you on how to set them up. Once you do, you can use my Webcore pistons (the ones meant for 3 switches) to keep STHM synced. Donât bother with the 2 switch solution until youâre more comfortable with this stuff.
As for the github code, youâre likely changing one of the Honeywell Partitions (try to rename so you can distinguish it). Before you actually use it, make sure your SmartThings Node Proxy solution is set up fully, and all your devices are added. Then go into the IDE to Devices. Open the âHoneywell Partitionâ device, click edit, find the Device Handler drop down list, and select the new DH that you just renamed. The list is long and alphabetical for all of the stock DHâs, and all of the custom ones are at the bottom of the list, so look down there.
One odd behavior I noticed this morning. I opened my door before disarming, and thus started the countdown on my Vista which I disarmed before closing the door. But then I also started to get a lot of âintruder alertsâ from STHM until I opened the ST app, disarmed STHM and dismissed the alerts.
When I turned off the alarm on the Vista while itâs counting down I had expected my webcore Switch Sync piston to send the command to turn off my Arm Stay virtual switch, but that never happened.
Looking back at my logs, (last entry. phew!), I think the reason is because the dscpartition state was ânotreadyâ, presumably because an entry delay had just been triggered. Just wondering how I should handle this situation. I donât want to make it âready or notreadyâ because then itâd disarm whenever the door opened. Should I make another if statement that sets the conditions of going from armed to notready to ready? can it even handle that kind of sequence?
Log
+154ms ââComparison (string) notready changes_away_from_any_of (string) armedaway, armedstay = true (3ms)
+155ms ââCancelling condition #50's schedules...
+156ms ââCondition #50 evaluated true (7ms)
+161ms ââComparison (string) notready is (string) ready = false (1ms)
+162ms ââCancelling condition #51's schedules...
+163ms ââCondition #51 evaluated false (6ms)
+164ms ââCondition group #41 evaluated false (state did not change) (15ms)
edit: still thinking about the conditions and triggers to make this work.
This is my current statement, which works properly when the alarm is disabled at the Vista before any doors are opened which would send it to a ânotreadyâ state.
if
Honeywell Security's dscpartition changes away from any of armedaway, armedstay
and
Honeywell Security's dscpartition is ready
But since ready and notready are very common states, I canât just add ânotreadyâ to the changes_away_from group, or else itâll be turning off my Armed VSâs every time the door opens (goes to notready) and shuts (goes to ready if disarmed). Sure those switches should already be off most of the time, but Iâd rather not pepper them with off commands unless it really doesnât matter.
I think I need the sequence to consider going from armedstay or armedawayâŠto notreadyâŠand then to ready. I imagine Iâd need to be storing those states into a variable to properly track the 3 step sequence. Is there a good way to write that?
Yesterday was nice so I had all the windows open, which means my vista was in âfaultâ state for several hours. I log the output of the node script so I can diagnose problems, and one did develop after about 3 hours. it shows this on my log several times in a span of 3 minutes.
[2020-09-10T15:11:45.783Z] [stnp] Notify error: Error: connect EHOSTUNREACH 192.168.1.21:39500
then it goes back to normal for about a half hour and starts giving me ETIMEDOUT errors for the rest of the day. I know from experience that this is the cause of the problem when I look at my sensors and theyâre not showing the correct state, and the way to fix it is to reboot the ST hub, and then open/close any sensor that are out of sync.
anyone know what causes this? i get the ETIMEDOUT error every few months, but it seems most noticable during periods when I leave a bunch of windows open all day. am i overburdening the ST hub?
Updated my DTH to @philh30âs latest DTH. Partition status updates whenever I arm from the alarm panel but nothing happens when I arm or disarm from ST. Stays stuck in sending status. However, it works when i switch back to the previous DTH. Anyone else experiencing this issue?
