ds7771

Thanks! Glad it’s not going away. Look forward to the new integration.

Today I received the following message in my HA dashboard. Can anyone provide insight about what exactly this means? I could not find any further details. Is there a list of features that stop working in 2023.5.0?

It says v.46 on my device. I have no idea what is shipping today. It seems odd that battery power works fine, while USB power reverts to different behavior. I wonder if this is a bug.

Upon further testing, I discovered an interesting twist that explains my problem: I was using Motion Sensor II with a USB power supply. When I switched to battery, the issue did not occur. Tested this multiple times. I can confirm that the "as motion sensed" option appears to work only when Motion Sensor II is powered with a battery. When powered with a USB power supply, for some unexplained reason, the functionality for sensing "as motion is sensed" is not active. Can Michel please comment if this is known behavior, or a bug? Thanks!

Hi Bumbershoot-- Thanks for the screenshot. Indeed, I do have the Motion | Condition option set to "always", but it still shuts off the light after the prescribed timeout. It does not reset the timer as it senses motion in the room. I wonder if you have a different version of the motion sensor? Mine is an early model, and I have kept it on the shelf for 2 years waiting for UDI to support it. The label says 2844-222 R1.0 2716. Is it possible that occupancy mode is not supported by ISY for R1.0 of the device?

Hi All-- I decided to upgrade to 5.0.13A and have another go at adding the Motion Sensor II to my environment. Previously I was aware that not all features were supported in back level versions of ISY so I put it on hold until 5.0.13A was released. I am pleased to see that there are certainly many more features supported now--a real credit to the UDI team's efforts to reverse engineer the device. However, I cannot seem to find any option to set the sensing mode to "as motion is sensed" rather than "after timeout". That was a basic option available on the old Motion Sensor I device. Without that option, it does not seem practical to use the Motion Sensor II as an occupancy sensor. Am I missing something important? Can anyone confirm that the "as motion is sensed" option is not supported for Motion Sensor II? Is there a recommended workaround to use Motion Sensor II as an occupancy sensor? Thanks! Dan

I tried the solution proposed above, but I do not think this can work for me. I have a need to disable motion sensing on certain days of the week, and instead turn the lights on and off using a timer that is based on the time of day. If I follow the technique to disable motion sensor (by adjusting the on level to zero inside the scene), then this seems to conflict with the timer because the on level is zero when the timer wants it to be 100. Using this technique, I cannot figure out any way to have the timer keep the lights turned on or off for the duration of the timer period, while simultaneously ignoring motion sensing. Any ideas?

Thanks for your reply. Thats a very good point. I don't use direct links because I have always preferred the control of programs, but in this case I seem to be shooting myself in the foot. I did once use direct links. I have a specific requirement to disable the lights on/off trigger at certain times, and I could never get the direct link method to handle this very well. I am aware of the method for disabling motion by adjusting on level to zero in the scene.....but I could just never get it to work smoothly for me. I also felt that this method created a lot of unnecessary traffic in ISY for adjusting scene levels every time the sensor was triggered, versus the program method which seems to shut down any further traffic after ISY determines that the program is in a disabled state. I think I will try going back to direct links. Is there a recommended method for disabling motion, or is adjusting the scene level pretty much the only way to do it?

Hi all. I am stumped. For a long time I had been using "flag" programs functionally as state variables. For example, I have a couple of motion sensors in the basement. I wrote a simple occupancy program to turn on the basement lights when either motion sensor is switched on. I saved the state of the motion sensor using the flag program--sensor on means "true" and sensor off means "false". Recently I decided to switch from flag programs to state variables. Should behave the same way, right? Wrong. After switching to state variables, the programs looked correct on paper, but did not switch off the lights. The state variable changed correctly. ISY correctly reported that the lights were in an off state. And the logs confirmed the that states did indeed change, and the new state did in fact trigger the lights to an off state. Everything looked good, but the lights were still on. This happened many times more than randomly, but not all the time. Maybe 50%. After much frustration, I decided to try adding a 5 second delay after the state changed before the program was triggered. That seems to have fixed the problem. I conjecture that the ISY processes changing flag programs more slowly than changing state variables. Due to this lag, changing flag programs leaves sufficient time for the PLM to sort through the communications that are going on at the same time. However, changing state variables is processed more quickly which causes a bottleneck in PLM communications. Some communications are lost in transit, hence the failure of lights to actually turn off even though ISY logs show them off. For some reason this only happens with this particular basement light switch. I am guessing the basement switch just has poor communication in general. I hate it when I don't know why things happen. Does this sound reasonable, or am I missing something else? Anybody else have this experience? Thanks!

Thanks for that clear explanation! I have a linux box, i.e., the Synology NAS. But it is headless, not connected to a monitor. I suppose I need to install a graphics driver on the Synology box and then connect my iPad browser to that socket. But I am not advanced at Linux, so this seems out of reach for me without a step by step tutorial. I think I will try running a docker container of a standard Linux distribution with VNC capability. Then I can VNC into the Linux instance on docker, and run the ISY console from the docker Linux instance. Seems a bit cloodgy but I am out of other ideas! Thanks for helping think through this.

Shot in the dark-- Does anyone have a tutorial or theories about how to run the admin.jnlp web start app on a Synology box? I would like to be able to write and modify ISY programs from an iPad web browser. Since iPad will not run java, I thought perhaps I could get the Synology box to run the ISY java app, and then access the ISY GUI through iPad web browser. I can run Docker containers but not sure what docker project would work for this. Have tried Tomcat, but I must not be doing it right, because the app would not load Unfortunately I am not a linux genius, but I have some basic competence with CLI. Any ideas would be much appreciated!

I upgraded from 4.6.1 to 5.0.10. I installed the upgrade per the instructions: by opening the 5.0.10 UI and then following the prompts to upgrade the firmware to 5.0.10. The 'about' menu reports that both firmware and UI v5.0.10 are currently installed. however, there is NO "node server" tab/menu in my administrative console. Did I do something wrong? How do I get the node server menu? Much appreciated, Dan

OK, thanks! So as long as ISY does not care about the mismatch then I will stop trying to restore devices to make these records match.

Hi all-- I cannot figure out why the ISY constantly shows a particular mismatch in one of the link records for all my devices. All devices have a link entry for the PLM. In my case the the PLM address is 3D.93.6B ISY shows this entry with an "E2" flag (which I understand represents "controller" status) like this: 2 : 0FE8 : E2 01 3D.93.6B 01 00 01 However, the device shows this entry with an "EA" flag like this: [Record mismatch] 0FE8 : EA 01 3D.93.6B 01 00 01 ISY reads this as a mismatch. I have no idea what "EA" flag means. I have tried restoring the device from ISY. This fixes the mismatch temporarily. But after a while, the device seems to reinstate the EA flag on its own initiative. Can someone please help me understand why this happens, and does it impact operation of my network in any way? Thanks! Dan

Hi, I am wondering if anybody knows of a way to integrate the ISY with an FBII XL2T alarm panel? I dont really care to do complicated things like view the status of zones or events. My main goal is simply to send basic enable/disable command remotely, as if punching the keypad locally. These panels seems to be pretty common in residential setups...there has to be a way to make this work with a little retrofitting. Thanks!