Release 3.2.1 (Beta) Is Now Available

[apostolakisl]

I just downgraded to 3.1.17 and it is still doing it. I deleted the "home and away" stuff off of the somee.com server just in case it had something to do with it and that didn't fix it either.

 

It is happening 100% of the time now, except, it never does it twice in a row.

 

In other words, if I turn the light on to any level, then off, the program runs and it goes to 25%. If I turn it off from there, it does not run. Also, If after the program runs and it goes to 25%, I then ramp the light up to 100% and turn it off, it does not run.

 

This is very frustrating!

[apostolakisl]

After thinking about things, I recall having the light mis-behave the day before I upgraded. Then I remembered we had a thunderstorm the night before with a power failure.

 

I watched the status of my lights on the ISY console. It was failing to track changes in most of my lights when applied locally. Queries worked instantly. I tried power cycling the ISY and the PLM and now it is tracking everything again.

 

So, perhaps the ISY and/or the PLM got into some screwy mode during the power failure and a clean power cycle fixed it. ??? It does not appear to be the 3.2.1 upgrade I don't think.

 

ALSO: One of my KPL's that used to glow at a low level when the buttons were off, now shuts the buttons down to black when off. This coincided with the other issues. I was only able to fix this with a factory reset.

[bpwwer]

Since installing 3.2.1 I'm seeing invalid information in the Irrigation module's "Irrigation Requirement" output.

 

Light                        12.6 %
Light Rate                   2.2 %/h
Evapotranspiration           0.1356 inches/day
Irrigation Requirement       --214748.352 inches
Yesterday's Water Deficit  0.1163 inches

 

Wouldn't be too bad if the number was just wrong, but the "--" causes my software to throw an exception when trying to parse it.

[RLIKWARTZ]

Has anyone tried to restore from a backup made by 3.2.1? I tried just recently and it had thrown away devices and device folders and put some scenes at the end of the tree and removed them from their folders. I had to go back to 3.1.17 and restore and then upgrade back to 3.2.1 and everything was fine. I've not tried it again to see if it was a fluke. I just thought I would check with others.

[Michel Kohanim]

Hello bpwwer,

 

This is quite strange. Does it revert to a good number after cycle complete? Does it ever correct itself? Is this an event or when you go to http://isy/rest/climate? Is this the same that you see in the Admin Console?

 

I am not sure where those -- are coming from. We shall take a closer look.

 

RLIKWARTZ,

 

We have not tested restoring a 3.2.1 backup on 3.1.17 (we normally do not recommend this as it's very difficult to support forward compatibility). This said, I suspect it would not work since we had to modify the nodes to add information about I2CS characteristics.

 

With kind regards,

Michel

[andrewm]

Fanlinc experiences with 3.2.1

 

Mixed bag of results installing 2 new Fanlincs over the weekend, though no disasters.

 

• 
  [*:1efvxq85]After adding each of the new devices, ISY showed the initial motor status as LOW, when the actual status was OFF.
  [*:1efvxq85]Neither Fanlincs would respond to scene commands after initial install, though they would respond to direct control from the ISY. Investigation showed the links table only had the ISY in there, not any of the scenes. After a few manual "Restore Devices" things worked OK. Seems a bit suspicious the same thing happened with both devices, but it could just be bad luck.
  [*:1efvxq85]Observed weird behavior on one of the Fanlincs, whereby the Fan light would occasionally come on at varying power levels, when the fan motor was being controlled. The motor control was being initiated from a RemoteLinc by way of ISY Programs/ State variables. This happened 3 times, but I couldn't reproduce it on demand, nor when I was capturing events! I don't know at this stage if this is an ISY issue or Fanlinc issue.

 

Questions / suggestions:

 

• 
  [*:1efvxq85]Can ISY be made to operate the internal Fanlinc beeper? This would be useful to provide feedback when changing speeds.
  [*:1efvxq85]Could I suggest using the word "motor" when auto-naming the device when it's added, rather than "fan". Reason being is that The root device name probably already includes "fan", in which case you end up with two new devices: (eg) "fan-light", and "fan-fan"! using ""motor" would makes things more obvious and less ambiguous.

[C Martin]

Yes, I did a successful restore from a backup last night... no problems.

 

Clarence

[RLIKWARTZ]

Ok, thank you. Maybe I'll try it again.

[RLIKWARTZ]

Ok, I tried a restore again and everything is fine. Don't know what happened.

[bpwwer]

Hello bpwwer,

 

This is quite strange. Does it revert to a good number after cycle complete? Does it ever correct itself? Is this an event or when you go to http://isy/rest/climate? Is this the same that you see in the Admin Console?

 

I am not sure where those -- are coming from. We shall take a closer look.

 

Michel

 

Nope, I think it started after updating to 3.2.1. I noticed because the plug-in for HomeSeer started crashing (unhandled exception trying to parse the value) after that update.

 

Same value via rest too. All methods to report the climate values report that value. It doesn't look like it's changing either. I've changed some of the irrigation module values, enabled, disabled, changed the weatherbug station. None of those has had any effect.

 

I have not tried re-booting the ISY. I can leave it like this and experiment with it. I don't need the value to be right for anything.

[RLIKWARTZ]

I actually restored from a 3.2.1 backup and that's when it broke. I then reverted back to 3.1.17 firmware and restored from a backup of that config and it worked I then did the 3.2.1 upgrade and I was fine. This morning I tried restoring from a 3.2.1 backup and it worked so I'm not sure what happened.

[LeeFleishman]

FanLinc experience with 3.2.1...

 

I have experienced similar anomalies as reported by andrewm...

 

1. Admin Console shows current state of fan (motor) as "LOW" when in fact the motor is off. Moving the slider to the OFF position, and then querying the fanlinc-fan node causes the fan's indicated current state to revert back to "LOW"

 

2. Turning the fan off via RemoteLinc often causes the fan light to turn off (fan light is definitely not a responder-member of any of the fan-motor scenes).

 

I'm using a 6-button KPL to control the fan light and motor (large ON & OFF buttons for the light, A, B, C, & D buttons for fan Med, Hi, Low, & Off respectively). MobiLinc correctly shows fan state, by relying on four distinct scenes: Fan OFF, Fan Low, Fan Med, & Fan Hi. RemoteLinc controls fan speed exclusively via programs. To accomplish this, I had to create a total of eight scenes and eight programs (not relying on any variables). Although it all works as intended (with the exception of anomaly #1 above), it just seems to be way too much overhead...just to control (and accurately indicate) fan speed/status. There has to be a simpler way.

 

Lee

INControl Home Automation

Thousand Oaks, CA

[LeeG]

LeeFleishman

 

The FanLinc Query does not return the actual On Level of the Fan side of the device. The number that comes back on the Query is in the Low speed range thus the On Level is changed to Low. Same number comes back on the Query regardless of the actual current Fan speed or Off.

 

It may take a command other than the standard Query to get the actual On Level of the Fan. I tried an extended command I thought might do the job but it does not provide an accurate Fan speed.

 

I think the Light responding when the Fan motor is turned Off is an issue with the FanLinc hardware. You can verify that by disconnecting the Fan (motor) connection of the FanLinc. Light does not seem to be affected when the motor is not connected to generated a back EMF (that may not be the correct term) when the motor is turned Off.

[Michel Kohanim]

Hello bpwwer,

 

Is there any pattern (i.e. does it happen all the time for all your customers)? I just cannot reproduce it here but we have to get it fixed in case there's a bug. Would it be possible to change your station to see if you still get the invalid characters?

 

RLIKWARTZ, thanks so very much for the update. There has been one report of system hang for which we have already implemented a fix. The issue was in the file system and I am thinking that perhaps the two issues are related (hopefully).

 

LeeG, thanks as always for your detailed analysis and explanations which are 100% accurate.

 

With kind regards,

Michel

[andrewm]

I think the Light responding when the Fan motor is turned Off is an issue with the FanLinc hardware. You can verify that by disconnecting the Fan (motor) connection of the FanLinc. Light does not seem to be affected when the motor is not connected to generated a back EMF (that may not be the correct term) when the motor is turned Off.

I did wonder if it was some sort of induction from the motor. The only hesitation I'd have on that is that I did see a correlation between the light-level and the requested fan speed. Hard to narrow down in the manner you suggest because it can't be reproduced on demand - it occurs only occasionally (for me).

 

Assuming its a hardware problem, do you think this is common to all Fanlincs, or do we have faulty units?

[LeeG]

andrewm

 

I don't know. It has happened so infrequently it is hard to pin down. In fact I had dismissed it until it was mentioned on the forum. I have FanLincs Rev 1.0 (v.3B) and Rev 1.05 (v.41) with the later being an I2CS device. Have not seen it at Rev 1.05 but I do not consider that meaningful at all. It is much too rare to reach that conclusion. Could even be a difference in the motors although they were purchased at the same time years ago.

[dstanley]

Odd thing that is happening but it had worked under 3.1.17 (although now I think this was never supposed to work!?)

I have a scene with a 2486D Keypadlinc Dimmer 6 Buttons v.35 in it (it is the LOAD) and the Scene B button of the same Dimmer as well - both are controllers.

I had the Scene B button turn on the load at a lower light level (35%) for a night light effect and the Main Button turned on the load at 65%

This combination was working previous to this update ...

I am right in now assuming that this combination should not have ever worked correctly?

 

Dwight

[mumpers]

Having issue with TempLinc. If I set the thermostat mode to auto on the device itself, it is set correctly, but if I use that in a scene to set home/away temps, it sets the thermostat to program auto. This is a problem because the thermostat then changes the setting to the local program ones which are not consistent with the scene.

[LeeG]

dstanley

 

Just updating the ISY image should not have changed anything in the KeypadLinc. If some change to the Scene was made then there could be a problem. Suggest doing a Restore Device on the KeypadLinc. It may be necessary to make a small change in the On Levels for both Load and B buttons to get the correct settings after the Restore Device.

 

I set that Scene up on a v.36 KPL 6 button Dimmer. Button B brings it to 35%, ON brings it to 65%. I have done a Restore Device on this KPL for other reasons.

[bpwwer]

Hello bpwwer,

 

Is there any pattern (i.e. does it happen all the time for all your customers)? I just cannot reproduce it here but we have to get it fixed in case there's a bug. Would it be possible to change your station to see if you still get the invalid characters?

 

With kind regards,

Michel

 

No one else has reported it so I don't think it's widespread and maybe just me. I have changed the station a couple of times with no change.

 

The only thing I haven't tried yet is to reboot the ISY. I'll try a reboot and save off the log before and after.

[LeeFleishman]

LeeG & andrewm...

 

I'm fairly certain that during my testing I have seen the fanlinc light turn off in response to a fan off command sent from RemoteLinc, even though the fan was actually off at that time (the fan off command from RemoteLinc is used as one of many possible triggers in some of my ISY programs). Since the fan was not actually running when the command was issued, and yet the fan-light turned off (improperly) in response, I have my doubts about it being due to inductive kickback from the fan motor. I'll keep testing...

 

As for the fanlinc motor's current status reporting to Admin Console as "LOW" following a query (when the fan is in fact off)...I have confirmed that the behavior exists regardless of the fan's actual speed/state. This seems to me to be a design deficiency. I've raised the issue with the folks at SH...their initial response was that when they tested for the behavior using HouseLinc, the fan motor's current status is always correctly indicated. On that basis, they threw it back on the ISY. It's very curious to me though, that I am able to successfully use the current status of the fan motor in ISY programs (e.g. IF / Status / FanLinc-fan / Is / Med / Then / Set / Scene 'Fan Indicator Med' / On ). On that score, I'm going to treat it as, "If it ain't broke, don't fix it."

 

LeeFleishman

[LeeG]

LeeFleishman

 

For sure the light turning Off when the Fan is not running is not the EMF issue I was thinking about. If you can ever catch that situation with an Event Viewer running at Level 3 I would love to see the trace.

 

There is a generic Standard command that ISY issues to satisfy a Query request. For sure the FanLinc, being that it has two nodes (Groups), is not returning the Fan state. There is a general Extended command that most devices support which returns device information. The Extended command does return the Light On Level and Ramp Rate. For HouseLinc to get the correct Fan state there must be a variant of that Extended command that pulls the Fan information. I'm sure that is documented in the Developer section on SmartLabs web site but it requires a paid subscription to get access. I would buy a developer subscription but one has to sign an NDA and that I will not do. I'm sure this is something the ISY will support in a future beta drop.

 

Thanks for the feedback on the Fan/Light interaction.

 

Lee

[dstanley]

LeeG,

You are correct again, following your instructions has my scene being controlled properly again. Thank you!

[Michel Kohanim]

Hello mumpers,

 

Can't reproduce here ... would it be possible for you to send a screenshot of your scene containing the templinc to support@Universal-devices.com?

 

Thanks and with kind regards,

Michel

[bpwwer]

Hello bpwwer,

 

Is there any pattern (i.e. does it happen all the time for all your customers)? I just cannot reproduce it here but we have to get it fixed in case there's a bug. Would it be possible to change your station to see if you still get the invalid characters?

 

With kind regards,

Michel

 

No one else has reported it so I don't think it's widespread and maybe just me. I have changed the station a couple of times with no change.

 

The only thing I haven't tried yet is to reboot the ISY. I'll try a reboot and save off the log before and after.

 

Ok I rebooted and looked through the logs. Nothing in them that indicates any problems, but the the same "--214748.352" value is still there in Irrigation Requirements.

 

I tried changing all the various irrigation settings (tried all regions, tried setting allowable depletion to zero, etc.) the value hasn't changed. Seems to be stuck at that one value. All the incoming weatherbug data seems valid and correct.

 

What can I do to reset this value? Is there a config file I should delete?