Jump to content

Inaccurate state showing in dashboard


Recommended Posts

Hi all,

New guy here.  I'm learning and I see the potential here, but I have a reliability issue here that may make me abandon the whole setup.

 

I have an isy994i with 2 Dual band in-line linc switches to control a hot water boiler and a circulation pump in a Laundromat.  There is 3 phase power and I have devices bridging the phases.

I am having a problem with the 2 inline lincs showing on while the load is off and vice-versa. 

If I go to the admin console where the state of the load is indicated, for example it shows on when the load is actually off, and I press on, the load will actually turn on.  Sometimes they indicate correctly, sometimes not. 

Is this a communication issue? How can I tell?  In the past when I didn't have the phases bridged, there would be an exclamation point appear on the admin console.  The inline lincs are both on the same circuit, and they are both on the same phase as the PLM.

 

Link to comment
Share on other sites

I

 

I have that happen with iolincs. However, while the dashboard / admin console does not show the right value, programs see the right value and function correctly.  Do your programs function correctly?

I would have to say that the program doesnt recognize the proper state either. 

I have one program for each device that turns the device off after being on for a certain time period, and I have caught them being actually on when an off state is wrongly displayed.

Link to comment
Share on other sites

I've had some interesting missed events when switching motors.  I have an old ApplianceLinc (power-line only), and noticed that it often had some comms failures when it turned on.  I theorize that during the period of time that the motor is starting, there's enough noise on the power line to make it faile (or perhaps just enough signal suckage, or even perhaps the motor's starting windings are sucking enough current to drop the line voltage at the ApplianceLinc enough to mess up its comms).

 

For my most critical application -- monitoring a septic lift pump for overlong run times -- I have a syncrolinc that senses the current draw when the pump runs.  I found that comms were unreliable until I set the syncrolinc to delay the "on" notification for 10 seconds or more.  Again, I theorize that the motor startup is interfering with the comms.

 

In your situation, what you might try is to create a monitoring program to catch and fix the out-of-sync situation -- try creating a program that runs every minute or so, and simply queries the device's status.  It doesn't actually have to do anything with the status, just querying the status should be sufficient.

Link to comment
Share on other sites

 It could be that the pump, the boiler, or both, are creating noise as soon as they are turned on and its overwhelming the insteon network and further message sometimes don't make it back. Or, that messages to turn them off don't make it.

 

Can you do a test of simply turning each on and off separately multiple times from the ISY, no programs.  (if doing that does not hurt the pump and boiler). 

See if using query eventually give you the right response, or if you ever get a !

 

Even though they are dual band, I have had cases of line noise totally 'possessing' a device and it stops functioning correctly. If this turns out to be the problem, filtering the pump and/or boiler will be the answer. I had to do that to my old furnaces, similar kind of problem

Link to comment
Share on other sites

I would not be surprised if electrical noise from the motors caused communication issues. I sort of expected it.

 

My concern about this setup is that it is possible to have a different state from what is indicated.  My understanding of the system while I was researching it was that there was error detection and message acknowledgement.  

 

mwester: by querying the device, what will that accomplish.  My programs don't rely on the state of the controlled load, only a motion sensor.  I'm not very gifted in the programming arena yet.

 

paulbates: what type of filtering do you recommend?

Link to comment
Share on other sites

Insteon is very reliable, but some sources of noise are extreme.

 

I use these: XPNR

 

I used 1 each on my old furnaces (the new furnaces motors aren't noisy and don't need them)

I use them on low voltage lighting transformers. I have several that respond incorrectly and intermittently without them

 

The advantage is that they relatively cheap, effective and very easy to install. Amazon has them for ~$20 each.

Link to comment
Share on other sites

 

My concern about this setup is that it is possible to have a different state from what is indicated. <-- This is possible when comms are not reliable and noise makers / signal suckers are present. This can also be present if both sides of the electrical legs in your home are not properly coupled / bridged.

 

 

My understanding of the system while I was researching it was that there was error detection and message acknowledgement.  <-- Yes the system incorporates the most basic Ack / Nak and error correction. But all of this assumes a perfect timing and no interference on the power line.

 

mwester: by querying the device, what will that accomplish.  My programs don't rely on the state of the controlled load, only a motion sensor.  I'm not very gifted in the programming arena yet. <- By querying the device the actual state will be known and corrected for not only visual display but for the program to execute correctly. Keeping in mind this is a band aid to a larger problem that the signal is simply not being received or generated.

 

 

 

Answers in line . . .

Link to comment
Share on other sites

Some other points.

 

- when ISY sends signals to a device it sets it's internal status to the last signal sent. If the device change fails ISY doesn't know it.

 

- when a device changes status by another mechanism (not ISY) it sends a status update to  ISY.  If ISY doesn't receive this properly the ISY status does not change and is incorrect.

 

For an experiment you could try putting a 'Wait X seconds' and then a 'Query of same device' after each operation of these devices from ISY. This may temporarily cure the problem and also provide more clues to resolve your alleged noise problems. If this does then selective removal of these lines would be cheap and easy to further pinpoint the problem. A simple beefy MOV across a coil may quench some contactor's inductive kick (counterEMF) that is spoiling proper Insteon reporting.

 

Posting your programs may allow others to find snags in your concept implementation, also.

Link to comment
Share on other sites

In a three phase power setup. The Zero Crossing of the AC is 120 degrees from each other and power line communications between phases will not work. As all the signal timing is referenced to the Zero Crossing.

 

Smarthome's original stand was only Insteon devices on the same phase in a three phase system would work. Though some with the 2443 Access Point found it would work on all three.

 

Now that most modules are Dual Band. Smarthome now indicates three phase systems are OK.

In a three phase system. Insteon RF is used to get commands between the phases and then power line or RF between the modules on the same phase.

 

In some instances a poor RF signal could effect things.

 

Some users have found a RC Snubber across the offending inductive load is a big help.

I can't find the part number at the moment.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


  • Recently Browsing

    • No registered users viewing this page.
  • Who's Online (See full list)

    • There are no registered users currently online
  • Forum Statistics

    • Total Topics
      36.8k
    • Total Posts
      369.8k
×
×
  • Create New...