Fortrezz MIMO2+ support

[MWareman]

5.0.12 - it seems I mistyped. I was wondering if the issue was resolved with this device before I ordered one.

Thanks!

Michael.

[Michel Kohanim]

Hi MWareman,

It's on the list of things for the upcoming release. 

With kind regards,

Michel

[MWareman]

Hi MWareman,
It's on the list of things for the upcoming release. 
With kind regards,
Michel

Thank you!

[KSchex]

Also impatiently awaiting MIMO 2+ complete ISY support.  Thanks Michael for putting it in the que.

Keith.

[MWareman]

I included my Mimo 2 - and got the following nodes (this is on 5.0.13A with the 500 series zwave board):

The first two appear to be duplicative of ZW 032.2 and ZW 032.4.

Selecting ZW 032.3 - I see status 'Off'. Hitting the 'On' button - the status changes to 'On' - and I hear a relay click in the Mimo device. The right-hand output status light lights up. After barely one second - the right LED goes out, the relay clicks again and the status in ISY changes to 'Off'.

This repeats with channel ZW 032.4 (except the left output status LED comes on and then off).

So - looks to be almost there for outputs (I have not tested the inputs yet). However - the outputs are momentary. I suspect this is a property I need to change though..

 

Edit: Parameter 1 and 2 sets latching time. Defaulting to 5 (0.5 second) if this is set to 0 it becomes non-momentary. Also to note - parameters are set on the 'WZ 032 Multilevel Sensor' node. The others give a blank error popup for some reason.

It would be nice to see UI options for momentary vs non-momentary (and setting the momentary timeout). The parameters are described int he tech ammendix for the device: https://static1.squarespace.com/static/57363221555986b60e62f0f0/t/5919d919ff7c50802f0b93da/1494866202716/Tech+Appendix+MIMO2%2B+8May2017+removed+MI+address.pdf 

Edited July 16, 2018 by MWareman

[junkycosmos]

I too was wondering where we are with MIMO 2+ support.   Seems very close.     Any thoughts on when we can change from momentary to latching such as we can with current mimolite on V4?

thanks MWareman for posting your results above.

 

 

[MWareman]

I too was wondering where we are with MIMO 2+ support.   Seems very close.     Any thoughts on when we can change from momentary to latching such as we can with current mimolite on V4?
thanks MWareman for posting your results above.
 
 

Momentary to latching is achieved by changing parameters 1 and 2 to ‘0’ (the default is 5)

[DCardellini01]

A bit confused on what is, and is not working for the MIMO2+ as of Nov 2018.

Has anybody verified proper operation of BOTH relays with v.5.0.14 software?

Thx in advance

[asbril]

2 hours ago, dcard said:

A bit confused on what is, and is not working for the MIMO2+ as of Nov 2018.

Has anybody verified proper operation of BOTH relays with v.5.0.14 software?

Thx in advance

Yes, I am also interested to find out. I am currently using 2 Mimo-Lites to operate a double rack of curtains. This works well with my ISY 99 % of the time, but occasionally it reports the wrong status (ON when OFF) and it will not correct the real status with a query command.

If MIMO2+ is fully operational with ISY (I use 5.0.14) then I should be able to have 1 MIMO2+ to replace my 2 MIMO-Lites and have ZWave Plus as well.

Edited November 17, 2018 by asbril

[KSchex]

I too am still waiting on MIMO+2.  I am holding back on two automation projects for the +2 compatibility.

Because of the lack of multi input support I have used WIFI and Beaglebones in some key home areas.  It would be nice to keep everything ZWave within the ISY and have a nice clean system.

 

[KSchex]

1 hour ago, asbril said:

Yes, I am also interested to find out. I am currently using 2 Mimo-Lites t operate a double rack of curtains. This works well with my ISY 99 % of the time, but occasionally it reports the wrong status (ON when OFF) and it will not correct the real status with a query command.

If MIMO2+ is fully operational with ISY (I use 5.0.14) then I should be able to have 1 MIMO2+ to replace my 2 MIMO-Lites and have ZWave Plus as well.

Hi Asbril….I don't know if this will help you but...I have found on some devices if I wait a second or two before asking for status or ask twice with a wait in between that 99% gets a lot better.  Not sure if it is the device or the ISY being busy, or a little of both.  Perhaps you have already tried this.

I have found there are occasional times when the ISY is busy and misses messages.  Especially in V5.  I stripped my system down to one device and one simple program and the Event Viewer to verify this.  With a sensor you tend not to notice it as much (even though it is there), but with a Wallmote keypad commanding a light through the ISY and a program it is very apparent when the ISY does not service the incoming message.  As a side note, the first thing I did was verify good RF signal strength and no external interference with a spectrum analyzer.  I realize this is above and beyond for some users but I was determined to know where my problem lies.

[junkycosmos]

KSchex,

Have you been in touch with UDI to report what you are seeing with the missed messages in a smaller setup ?   Seems that might be ideal given limited factors at play vs some of the more complicated setups trying to troubleshoot.    Your comment noting on V5 also caught my attention since my ISY is busy and sometimes checks out in v4 but due to having a lot of nodes.  The extra resource use on V5 has me hesitant to move to v5.  

 

All,

Regarding mimo lite (not the mimo2); when power is removed and reapplied they do falsely report status of the relay and sensor as ON regardless of real state.  However a query does then report correct status.     I too am curious on the mimo2 when anyone tries it with ISY.  

[asbril]

1 hour ago, junkycosmos said:

Regarding mimo lite (not the mimo2); when power is removed and reapplied they do falsely report status of the relay and sensor as ON regardless of real state.

This is indeed interesting as it may be the cause when I have ON reporting from my Mimo-Lites even though the curtains were open. Occasionally I make some changes in my automation that requires switching off power.

[DCardellini01]

Reading above responses for the Mimo2+ :

It appears that the MimoLite works, but does have some flakey behavior on reporting relay and sensor status.  This "could" be a an initialization issue associated with start-up.

But I do not see in the responses any "mostly" proper operation of the 2Relay/2Input Mimo2+

Does anyone have and use both inputs and outputs on Mimo2+ ?  Has anyone confirmed the same flakey behavior on status reporting for that particular model?

Has anyone used an input as an "analog input" with either the MimoLite or the Mimo2+ ??

Hoping that Michel will weigh in, as I know he obtained a Mimo2+ for testing some months back.

Edited November 18, 2018 by dcard

[asbril]

On 11/18/2018 at 9:22 AM, dcard said:

It appears that the MimoLite works, but does have some flakey behavior on reporting relay

This is exactly the issue that I have with my 2 Mimo-Lites. When I open or close the curtains with the remote control, then the change of status is not reported to the ISY. And Query will not give the current status either. As such I hope that soon the Mimo-2 will work better with ISY so that it will report status as it happens.

[DCardellini01]

Thx, Asbril for taking  time to respond.  I  am quite surprised that there are not more people deeply interested in a low-voltage solution for I/O as part of the ISY family of supported devices.   The MIMO2+ would have been the perfect solution for an HVAC application where I have with no available 110vac outlets.  I need to control two relays to select four different blower speeds on a fixed-speed air handler in attic (married to a new variable speed Bosch compressor installed outside)

It would seem that support for a simple Modbus TCP stack in the ISY would open the door to tons of existing product and DIY Arduino-type solutions.  I know that the TCP Modbus stack would be fairly trivial, but the necessary configuration support would take quite bit of effort.  Yes, I am aware of NodeLink, but really do not want (yet another) programmed part that I need to support for the next 10 plus years. Also, do not want to rely on WIFI for my automation backbone.

I am deeply disappointed in the Z Wave protocol that seems to leave too much uncertainty on implementation within both controller and devices.  The more I read, the more it seems that every new device or controller requires a period of time to shake out the bugs.  It would seem to be a nearly impossible task for a controller manufacturer such as Universal Devices to maintain their code base with never ending stream of flakey and unique device interfaces.

In any case, for this situation, I have resolved to get 110vac to my attic location and use a Smartenit EZIO2x4 to drive my two 24vac relays.  Hope there will not be disappointment on that path too, and just thinking that spending $120 for that one device is excessive.

What is so sad is that the industrial control market has matured to a point to provide products like these full-fledged Programmable Logic Controller (PLC's) replete with analog/digital I/O, embedded web servers with Ethernet for roughly the same price range as that stupid I/O module:

http://www.wolfautomation.com/media/pdf/smartrelay/idec/idec-flonef-competitorcomparison.pdf

(you can get an amazing spread of I/O and functionality for $145 )

In any case, thx for your input!

 

[asbril]

39 minutes ago, dcard said:

Thx, Asbril for taking  time to respond.  I  am quite surprised that there are not more people deeply interested in a low-voltage solution for I/O as part of the ISY family of supported devices.   The MIMO2+ would have been the perfect solution for an HVAC application where I have with no available 110vac outlets.  I need to control two relays to select four different blower speeds on a fixed-speed air handler in attic (married to a new variable speed Bosch compressor installed outside)

It would seem that support for a simple Modbus TCP stack in the ISY would open the door to tons of existing product and DIY Arduino-type solutions.  I know that the TCP Modbus stack would be fairly trivial, but the necessary configuration support would take quite bit of effort.  Yes, I am aware of NodeLink, but really do not want (yet another) programmed part that I need to support for the next 10 plus years. Also, do not want to rely on WIFI for my automation backbone.

I am deeply disappointed in the Z Wave protocol that seems to leave too much uncertainty on implementation within both controller and devices.  The more I read, the more it seems that every new device or controller requires a period of time to shake out the bugs.  It would seem to be a nearly impossible task for a controller manufacturer such as Universal Devices to maintain their code base with never ending stream of flakey and unique device interfaces.

In any case, for this situation, I have resolved to get 110vac to my attic location and use a Smartenit EZIO2x4 to drive my two 24vac relays.  Hope there will not be disappointment on that path too, and just thinking that spending $120 for that one device is excessive.

What is so sad is that the industrial control market has matured to a point to provide products like these full-fledged Programmable Logic Controller (PLC's) replete with analog/digital I/O, embedded web servers with Ethernet for roughly the same price range as that stupid I/O module:

http://www.wolfautomation.com/media/pdf/smartrelay/idec/idec-flonef-competitorcomparison.pdf

(you can get an amazing spread of I/O and functionality for $145 )

In any case, thx for your input!

 

Thanks dcard, as I reported elsewhere in this forum, I think that I identified why sometimes the ISY does not reflect the actual status of my Mimo-Lites. These are connected to automatic curtains that also have a handheld remote control. When opening or closing the curtains with the remote control this change of status is not reported to the ISY. As I pointed out earlier, my Mimo-Lites do also not respond to a Query command. I have written to Fortress asking them whether the Mimo-2+ is Zwave Plus with status reporting and I am waiting for their reply.

[DCardellini01]

Looking at the Fortrezz website, the MIMOLite does not appear to be Z Wave Plus.

But the newer MIMO2+ does say "...the latest Z wave Plus technology."

That would explain the lack of reporting status on that MimoLite.

Shocked that nobody has used the MIMO2+ and reported somewhere on these forums.

And I do see that Michel obtained a MIMO2+ some months back for testing.

 

 

[asbril]

On 6/11/2018 at 10:51 AM, Michel Kohanim said:

Hi Michael,

Are you on 5.0.10 or 5.0.12?

With kind regards,

Michel

Michel

If you are contemplating support for Mimo-2+ (and Mimo-Lite) could you check whether Query would work as these Mimo devices appear not to be Zwave Plus ?

Thanks

[asbril]

1 hour ago, dcard said:

But the newer MIMO2+ does say "...the latest Z wave Plus technology."

I saw that but I would like to be sure that this actually means Zwave Plus, and of course we want to know about ISY compatibility, as the specs of Fortress devices appear to need tweaking to make them work with ISY.

[Michel Kohanim]

@asbril,

Definitely but it will have to wait till we get our Z-Wave+ certification.

With kind regards,
Michel

[DCardellini01]

26 minutes ago, Michel Kohanim said:

@asbril,

Definitely but it will have to wait till we get our Z-Wave+ certification.

With kind regards,
Michel

Michel:

Great!  So it is in the works.  Rough time frame?...weeks away, months, year?

Also, I notice there there is a Z-wave dongle 500 series that has been put in place.  I bought a Z-Wave add on from Orchestrated Home in May 2018.

I cannot find any references here about advantages of that 500 series, and if it is needed for the Z-Wave+ cert?

Thx in advance!

[KSchex]

Nothing against any of the manufacturers, but this is why I have begun using Beaglebone Blacks with HTTP Get / Post and my own optically isolated IO.  With this I have over come the single point problem.  I still believe Z-Wave and most of the controllers were meant to be a consumer product, designed and manufactured in China with the attitude of sell a bunch and move on, as I have "moved on" through many trash devices.  We as serious ISY users have taken this a step further; relying on this for daily performance of home automation.  In my case I am disable and rely on it to do it's thing when I press the button, as advertised.

As for MIMO, I have several Lites in my system but rely on them to report their status change and do not query them.  In all cases I use the input to send me the status of the controlled device.  The lack of support for the 2+ and long software  lead time is what drove me to the Beaglebone solution as I could not wait any longer.  It is unfortunate because they are well built little devices that I have found are easy to deal with and don't get confused with power failures.  It has been quite a project. 

Thanks all for airing your views and findings as well as Michel for his undying support and assistance. 

Edited November 26, 2018 by KSchex
fingers did not work well with brain...

[asbril]

1 minute ago, KSchex said:

rely on them to report their status change and do not query them.

Interesting that you have Status reporting from your Mimo-Lites.  I do not. Of course the status is properly reported when the status is initiated in ISY, but not when the ON/OFF changes when opening the curtains manually or with the remote control.

[DCardellini01]

52 minutes ago, KSchex said:

Nothing against any of the manufacturers, but this is why I have begun using Beaglebone Blacks with HTTP Get / Post and my own optically isolated IO.  With this I have over come the single point problem.  I still believe Z-Wave and most of the controllers were meant to be a consumer product, designed and manufactured in China with the attitude of sell a bunch and move on, as I have "moved on" through many trash devices.  We as serious ISY users have taken this a step further; relying on this for daily performance of home automation.  In my case I am disable and rely on it to do it's thing when I press the button, as advertised.

As for MIMO, I have several Lites in my system but rely on them to report their status change and do not query them.  In all cases I use the input to send me the status of the controlled device.  The lack of support for the 2+ and long software  lead time is what drove me to the Beaglebone solution as I could not wait any longer.  It is unfortunate because they are well built little devices that I have found are easy to deal with and don't get confused with power failures.  It has been quite a project. 

Thanks all for airing your views and findings as well as Michel for his undying support and assistance. 

Yes, I do consider taking that same step you have taken (the Beaglebone or other).

First, I need to (emotionally) cross that threshold for using WIFI as my "control network."  I know this is inevitable, but haven't motivated yet.

Once I add that programmed device, Beagle or other, likely with NodeLink, I will be sorely tempted to use that device for my "Automation Programs" and use the just ISY as a device manager, for installation, setting up scenes, diagnostics,  repair and as the main interface to those devices (Insteon and Z-Wave today).  Universal-Devices has put a tremendous amount of effort into that functionality that just could not be replicated in another environment by a user.

As a controls engineer, the programming environment is just too limited in the ISY for me, personally.  The idiosyncrasies of the event-driven programming model means that when I do attack a new project...a year later, I have to relearn these things....like how programs execute,  avoiding "WAITs" with anything state driven, etc. etc.  

I have developed a consistent Mealy State Machine model implementation and try to fit (nearly) everything into a state machine, using external timers.  I still get burned by things like using math on a state variable, only to discover intermediate result calculations triggering other states (or different state machine).

But it works well for me as I have always done everything with Mealy state machines, regardless of platform (embedded, PLC's etc.).

Where I struggle is when having to duplicate a complex program (a set of state machines, timers, etc.).  Like a watering valve that serves dual-purpose as a pest eliminator  with motion sensors, or a "Zone" in an HVAC system with complex statistics calculations and logic.  When I want to add another identical "Zone" or Valve" it is just so painful.  When I want to make a fix to one "Object" (valve, zone, etc.) it is just horrible to attempt that paradigm on the ISY.

But I am an outlier for use cases.  ISY does a fantastic job for the geeky consumer and hobbyist.  I just have too much time on my hands

Edited November 26, 2018 by dcard