LeeG

Okay, thanks. That is not an I2CS device. The problem is likely the Dakota Alert code being defined before being added to the ISY. Delete the EZSnsRF, factory reset, then add it back to the ISY following the sequence in the UDI Wiki. That should sync the node with the Dakota Alert code which should cause the EZSnsRF node to turn On (very briefly) when motion is sensed. My test here shows the node being On for 1-2 seconds only when motion is sensed.

The current implementation is fine. In this case you want the additional On commands to trigger the Program again, restarting the Wait with a new interval. In Occupancy mode and On Only commands the timeout interval should not matter. Each motion sensed should result in a Motion On message with the Program being triggered. The timeout value should be at its lowest value as it can affect how quickly Dusk/Dawn is identified but it should not affect Occupancy mode motion messages. The Event Viewer at Level 3 can be used to verify that each motion detected results in a Motion On message. From memory the State variable works like If Status. The variable value has to change to trigger the Program. Like pressing a device ON paddle twice in a row. The If Status triggers only once since the Status did not change with the second ON. The old technique should have worked using +=1 so the variable value would have been incremented rather than sitting a 1.

Run Tools | Diagnostics | Event Viewer with Level 3. Right click the EZSnsRF node, select Diagnostics | Query Insteon Engine. Post the event log. The EZSnsRF likely has an I2CS internal PLM as the devices SHN has been shipping recently have the new I2CS internal PLMs. If the event trace confirms this ISY 3.3.2 is required as it contains support for SHN devices with an I2CS PLM. As far as definig the Dakota Alert code, it needs to be done as part of adding the EZSnsRF to the ISY which I believe will have to be done again once on 3.3.2. After going to 3.3.2 (assuming the event trace shows that to be necessary) delete the EZSnsRF, factory reset the EZSnsRF, add the EZSnsRF following the instructions in the Wiki. This procedure will define the Dakota Alert code as part of adding the EZSnsRF to the ISY.

That is not a universal clock response on 3.3.2 as the Admin Console time is ticking away at one second intervals. I have no optional modules and I do not sync with NTP

Unless the Motion Sensor is in Occupancy mode (Sensing mode) it will send only one Motion On command. The timeout interval has to expire before the Motion Sensor will send another Motion On command. In Occupancy mode (Sensing mode) the MS sends a Motion On command each time motion is sensed. Use the Red LED in the Motion Sensor to determine when it has detected motion. Although it does not send additional Motion On commands unless in Occupancy mode the timeout should be extended for each additional motion detected. That aspect of operation is all within the Motion Sensor itself. The ISY has no control over the extension of the timeout value.

The current Program does not have multiple conditions in the If section. On my system (3.3.2) the only time the AND and OR buttons appear is when the Program has multiple If conditions. Without multiple If conditions the AND and OR buttons have no purpose. Try adding an additional condition to the If section only for a test.

One link record for each Dakota Alert code added to the EZSnsRF. There is no link to the Dakota Alert Motion Sensor. The EZSnsRF is looking for an RF signal that matches the Dakota Alert code that was defined. The all zeros link record entry is the end of list entry. How was the Dakota Alert code defined to the EZSnsRF? Does the EZSnsRF node show On status for a second or two when the Motion Sensor sees motion. The Dakota Alert Motion Sensor does not stay on very long. What level ISY firmware is being used? Is this a new EZSnsRF?

Glad you found a way of getting a good download. The ISY image is multi layered. The automatic unzip strips the first layer, leaving a ZIP file but not a valid install file. If you ever want to install a Beta the manual update method is the only way. In that case turn the automatic unzip option off or use the original download that the mac put into the trash when it unzipped the first layer. That is the first time I have seen that approach suggested but it sounds like it would work.

Every device added to HouseLInc that can present status (trigger an event) must have a link in the device pointing to the PLM. An 8 button KPL has 8 link records pointing to the HL PLM, one for each button. A 6 button KPL has 5 link records pointing to the HL PLM. All of these links are created when the device is added to HouseLinc. Has nothing to do with Scenes that may have been defined in addition to what HouseLinc does under the covers. The ISY does the same thing as it is in Insteon requirement. Edit: the PLM has a corresponding link for each of the device links. Deleting a PLM could easily drop that many links (Scenes) Pick a device, do a Show Device Links Table and Compare. Analyze the differences to determine what the issues are. Cannot suggest an approach until each of the link record issues is understood. Did the spider process miss some device link records. Edit2; when you added the devices to the ISY that is the option you chose "add devices found in links and keep existing links". It is part of the device add process. EDIT3: the dimmer switches and inlinelincs account for 33 Scenes gone when the HL PLM was deleted. Depending on the type of KPL (6 or 8 button) an additional 40 to 64 Scenes are accounted for. Lots of Scenes went away when the HL PLM was deleted.

The next scheduled run time reflects the end of the time range (+11 hours) when the Program will be triggered, driving the Else clause. What does the Activity column show when the Program is running? EDIT: the Repeat statement does not cause the Program to be triggered again as the Program would start over from the beginning of the Then clause, not the beginning of the Repeat loop. The Activity column would be expected to show Running Then while the Program is waiting for the Repeat time interval to elapse.

There is some aspect of the Mac that unzips a file by default (maybe the browser). The ISY ZIP file cannot be unzipped outside the ISY as it makes the file invalid. There is an option the suppresses that automatic unzip.

The spider operation would have picked up the links between the devices and the HouseLinc PLM. When you say you Deleted the old PLM, do you mean the ISY had a device definition for the HouseLinc PLM and that is the old PLM that was deleted? If so when that PLM device was deleted it would have required deleting all link records in all the devices that referenced the deleted device. I know it seemed like a lot of work but it would have been a better idea to add each device with the 'remove existing links' option which would have eliminated the 'old PLM' references HouseLinc established. I am not sure what you have now besides a bunch of Scene xxxx definitions that need to be renamed to meaningful names and a bunch of devices added under the Name of the Insteon address rather than a meaningful name. I would make note of all the Insteon addresses and start over by deleting all the devices and adding each back with a meaningful Name. Then create ISY Scenes with meaningful Names. That way the system is clean from the start.

Xathros Thanks, I did go in the wrong direction. blueman2 Thanks for posting the information from Smarthome that LampLinc Load Sense has been discontinued. Did Smarthome give any indication of whether the Controller function of the LampLinc was discontinued? That is, if the side On/Off buttons are used does the LampLinc still function as a Controller and notify the ISY that the LampLinc has changed state. Long term the ISY would have to treat the LampLinc as a Responder Only device (like the ApplianceLinc) if they have removed this capability along with Load Sense. Having Controller capability makes little sense without Load Sense.

I think that method looks up the ISY uuid and gets the IP address from that. Perhaps the IP address has changed or the Java cache needs to be cleared.

Moshe Is this how the Admin Console is being accessed? I pulled this from the initial 3.3.2 post at the beginning of this topic “2. Important NetBios removed from ISY99 Series. You can no longer access ISY by going to http://isy on Windowsâ€

The REST command was accepted. That suggests the issue is not REST but the ability of the ISY to control the specific device. Use the Admin Console to turn the device On and Off. The Admin Console uses the same Insteon commands as the REST DON and DOF requests. Run Tools | Diagnostics | Event Viewer with Level 3 while the Admin Console On and Off commands (or the REST DOF) are being executed. If it is only an Off issue that is generally the load being controlled is generating interference when On to prevent the Off command from being received.

This was posted by Chris a few posts earlier in this topic... "This feature was only recently added to the Insteon thermostat adapters and therefore it is likely your adapter does not have the minimum firmware level of v.D4."

blueman2 If you Factory Reset the LampLinc and did not Restore Device the ISY cannot work with the LampLinc. That is an I2CS device which requires specific link records which were deleted by the Factory Reset.

Regarding the clock, neither has the required firmware to set the clock.

Run Tools | Diagnostics | Event Viewer with Level 3. Turn the LampLinc On and Off, post trace. What ISY firmware level is being used? Help | About will show Firmware and UI levels.

What is the result? What happens if the basic part of the REST command is entered into the IE command line? For example: http://192.168.2.4/rest/nodes/15 B2 6A 1/cmd/DOF

It looks very much like the other 2477 that NAKed everything after the first link record is written. I have a 2477SA1 with the v41 firmware in operation on a pump. I did use New INSTEON Device rather than Start Linking. Might try that as an alternative.

Without the actual Insteon device address hard to tell. No leading zeros 0A 0B 0C 1, should be A B C 1

brookbphx What level ISY firmware is in use? What does Help | About show for Firmware and UI level?

Thanks for the level 3 trace, had not seen the edit. The messages look fine. The duplicate Group Broadcast is normal for an RF device. It looks like the Group Cleanup Direct message is being treated as a separate event from the motion sensor. If that is the case it is a glitch in 3.3.1