bmercier

I spent a few hours today in an attempt to resolve this. First of all, here's some information about how device sync works; 1. Device sync works by Google calling a portal API which returns the devices AND the "agentUserId", which is a unique ID to identify the user. 2. Portal can call a google API (we call it the HomeGraph API) to trigger a sync. We call it a syncRequest. It basically tells GH to call us for a Sync (line 1 above). The authentication to the Homegraph API is system wide (it's not specific to the user). The payload in the request has the agentUserId which tells GH for which user to trigger a request. Please keep in mind that the logged in user MUST BE THE SAME AS THE ONE GH WAS LINKED TO. So, whenever we ask GH to "Sync my devices", only 1 is done. Whenever we go to ISY Portal and click on to send the spokens, 2 is done, which calls 1. QUESTIONS: 1. Now, to my knowledge, 1 usually works well. Only 2 stops working after a while, for some reason. In this case, Jimbo also has a problem with 1, as per the screen shot (Thanks for the screen shot). Now, does anyone else also have a problem with 1 (Vocally request "Sync my devices")? 2. Despite the PERMISSION_ERROR with 2, can someone confirm if the sync works when we get the error? According to the logs, the sync happens and returns no errors. Benoit

You don't need 2 accounts. However, you need to have 2 user profiles, one for each homes. For your 2 user profiles, login and click my profile, make sure that "Amazon Echo and Google Home ISY" is set to "Use preferred ISY", and set the preferred ISY to their corresponding ISY. Each Amazon account will need to link with their corresponding ISY Portal user profile. So the overall link is this: Amazon echo -> Amazon account -> ISY Portal User Profile -> ISY. Benoit

Thanks for the suggestion. The feature is now implemented for Alexa, GH and also IFTTT. Benoit

Please try again, it should be working fine now. Benoit

Looks like the address is wrong. Try: http://<your isy ip>/rest/nodes This will give you all of your nodes. From there, you can locate the kpl button node and try the url with the correct address, or just cut and paste the node from /rest/nodes Benoit

In a browser, go to: http://<your isy ip>/rest/nodes/<your kpl button address>

Please post the result of: /rest/nodes/<your kpl button address> Benoit

You are definitely using 1.1.3. Sent from my iPhone using Tapatalk

1. Search for the postback url in the log: 2020-01-20 03:41:12 info: NS: Starting Subscription with postback URL https://pgc-ns-ingress.isy.io/ns/ring-<uuid>-1/event 2. Try the url in a browser, but replace "event" by "test". You should get a message saying the test is successful. This simply tests the communication to the nodeserver. 3. Now try the url in a browser once again, but remove "event", let the url finish with the forward slash. You should get a message saying "Node server is healthy". If so, this confirms you are running 1.1.3. Benoit

Looks like a PGC bug where the version number is not updated. But clearly, the nodeserver is indeed updated to 1.1.3. Benoit

This feature will be added, but it's not scheduled yet. Benoit

I'm not sure why. PGC should bring the new version when restarting. That's what James is saying. Benoit.

To my knowledge, precision can't be passed. So I just send as many digits as required after the decimal point. Like this: /rest/nodes/<address>/cmd/CLISPH/23.5/4 This is how I set the value with the uom: const valueWithUom = (t.isInsteon ? newValue * 2 : newValue).toFixed(precision) + ((t.uom && t.uom.length && !t.isInsteon) ? '/' + t.uom : ''); Benoit

What is the device in question? Does it come from a Nodeserver? ISY Portal identifies a device using the hint of the device (the device category). If it is incorrectly set by the Nodeserver, it may incorrectly be identified as a thermostat. Those hints are considered thermostats: 1.12.x.x (Ecobee and other Nodeserver thermostats) 4.8.x.x (ZWave thermostats) 5.x.x.x (Insteon thermostat) Benoit

For the purpose of clarification, HAD is still available, both on ISY Portal, in the firmware, and as customization interface, and there is no plan to retire it. However, no efforts are planned to enhance it either. Benoit

Whenever possible, put these on the ISY side. If you do this on the Alexa side, one drawback is that to turn off let's say 30 lights, there well be 30 requests sent and queued for execution, so your lights won't turn on simultaneously. The second drawback is that if for some reason you have to unlink and restart clean, you will lose your Alexa configuration. The only time I would do that on the Alexa side is if you have devices coming from different skills that you want to control together as a group.

A contact sensor is not the same thing as a door lock. All a contact sensor allows you to do is trigger a routine. You can query the contact sensor state in the Alexa app, but you can’t query it vocally. Sent from my iPhone using Tapatalk

Thanks for the suggestion, instructions updated. Benoit

Looks like there is a low level problem. Insteon or ZWave communication problem or perhaps a problem with links. Sent from my iPhone using Tapatalk

There is something else at play. First make sure that you can control devices using web access successfully. Benoit

Communication pathway: 1. ISY opens a permanent connection with ISY Portal at boot time, and retries to connect when communication is interrupted. 2. ISY Portal sends commands to ISY through that connection, when required. A few security checks are done, such as the communication must have been previously approved in the admin console. Alexa command confirmation: The command is sent to the ISY in the same way as when using ISY Portal web access or the local UI. In other words, yes, there is a round trip to the ISY, and even to the actual device. Benoit

Recommended troubleshooting sequence: 1. Use the admin console or web interface from ISY to turn on/off devices. 2. Use the ISY Portal web interface to turn on/off these same devices. 3. Then try these same devices through Alexa. If it's a PLM problem, it should fail at step one. Step 2 helps you determine if ISY is communicating with Portal correctly. If it fails at step 3 only, then you know it's an Alexa related problem. If so, this can help you: https://wiki.universal-devices.com/index.php?title=ISY_Portal_Amazon_Echo_Integration_V3

I made a change to ISY Portal. Nodes with a hint of 0.0.x.x should now appear as a dimmable light. Can you please test it? Thanks, Benoit

Good catch, this is now fixed.

Try to delete the routine and create a new routine using the same ‘virtual’ motion sensor. Benoit Sent from my iPhone using Tapatalk