I appreciate your help. I'm not a developer and need to learn groovy. Maybe at someone the devs will put together some training. I'd love to be able to contribute to the code, but at this point I'm just a 
that can find problems. 
peng1can .. tks very much for confirming. I got my unit today and I see in the instructions the caution about input-to-relay mappings not allowing z-wave clear/set commands. But instead of 'hard mapping' the inputs to the relays, couldn't you just disconnect garage door button(s) and then wire the relay(s) to the wiring that the button(s) were connected to. Then if the MIMO was close to the button(s), you could wire the button to the MIMO's +16V and GND connections and configure the input as NO momentary (if that's possible). That way when the button is pushed, the input sees 16V and triggers an event and you could use the hub to monitor for those events and then trigger a relay which would have to be configured as momentary as well. Isn't that what you want to do? I think I read somewhere in the doc that the input has an internal impedance so that it wouldn't be shorting out the 16V supply when pushed but you'd want to check that. ...Ian
If I'm following what you're saying, we'd still be reliant upon Hubitat to relay the pressing of the manual button to the garage door motor. Although I would be more likely to trust hubitat for that than I am SmartThings, I still don't like the idea of an external dependency for the garage door opener. I don't want to take a chance that something happens with the hub and then I can't cancel the garage door closing.
If the processing was happening on the MIMO (which is what seems to happen if you set the input-to-relay mapping except that you lose the z-wave control), I would probably trust it and then have the added bonus of being able to track the button presses and maybe do something useful with that info.
I'm still not sure I'm completely understanding your requirements. If all you're wanting to do is to operate the opener via the button or the MIMO, then just connect one of the relays in parallel with the button. That way you'll still have manual control with the button. But if you also want to know if the button is pushed, then you'll have to create a way to monitor the button which is likely using low voltage AC and therefore not compatible with the MIMO inputs as they are DC only I believe. If you have some electronics experience, you could probably use a bridge rectifier and a couple of resisters to take the AC voltage and convert it to an acceptable DC level that would be compatible with a MIMO input. If not, you could probably buy a relay that would accept AC and then connect the switched side between the MIMO DC voltage and an input.
On the other hand, if you don't really want to know if the button has been pushed but you do want to know if the door is open or closed, just buy a cheap magnetic contact switch and mount it to the door and frame so when the door is opened, the switch will go from open (if its NC) or closed (if its NO) and if you wire one side to MIMO 16V and the other side in series with a MIMO input (plugged as NC) then the MIMO will detect the change. This has the added benefit of telling you if the button was pushed as well.
I started poking away at this today.
These are my implementation thoughts.
Two child devices, one for each of the two channels.
Children would expose switch and contact capabilitys.
Parent device would have the following options for each channel, however I'll enumerate the options for channel 1 for the sake of brevity.
Relay 1 control: manual, sig1, sig2, sig1 and sig2
Relay 1 auto off: disabled and various options from .5 to 3 seconds
Signal 1 trigger: inside or outside (essentially flips the input allowing nc or no contact sensors)
I'm going to skip all the signal voltage threshold options, if youre using those you probably have your own driver already...
When a signal input is bound to one of the outputs auto off is disabled and the on off commands from the children will not change the relay states, that's just the way this thing works.
Thoughts?
Is the inside/outside the intended label? If the purpose is to select NC/NO maybe keep the purpose/label the same so it's known it's to toggle NC/NO?
Trying to follow the terminology in the tech docs...
Cool... following what's in the docs is always best... then you can tell us all to RTFM! 
Glad to see you all doing the coding. I have zero programming skills. And kind of got the early code running. Looking forward to the new driver. Willing blind monkey tester. 
Hi Mike.
I agree. The sig voltage and meter pulse counter could probably be utilized in some oddball applications (like for curtains and roller blind control), but for the most part I think those features are probably more for the pocket protector and stainless ruler crowd.
Here is a typical use case: I have a long-range Dakota Alert driveway monitor. When someone starts up the driveway and breaks a laser beam, a signal is sent to the Dakota Alert base station. The base station then sends a bit of voltage to Sig 1 Input, which in turns triggers Sig 1 NO to close for 3 seconds. When Sig 1 NO closes, I fire off various triggers to turn on the driveway lights, back yard lights, ring a chime, etc. Sig 2 input and NO could be used to monitor a second driveway or a gate switch.
I think the setup you are describing would be flexible enough to accomodate most situations.
Thanks,
--Barry
Does anybody know if the Fortrezz MIMO2+ Hubitat driver supports readout of the pulse counter? I was thinking to monitor a water meter that has pulsed output and this is the closest thing I have found to an approach to integrate it. Thanks if any ideas.
1 Like
not working for me.. Missing Activation and multi second delay turning off or on 3 feet from the hub.. Guess ill send back to amazon and go back to the non + version i already have.. any suggestions.
did a repair on it and its trying to use 2 repeaters when it literally is 2 feet from the hub.. something wrong with this device.
weird excluded and repaired and working fine.. it was s0 before that could have had something to do with it.. now it is s2..
I was pondering this as a possible improvement over the Zooz Multirelay.
However, all this "trigger between" and "trigger outside" stuff related to the lower-low, lower-high, upper-low, upper-high is great for some complex things.
And, while it supposedly can (apparently) handle 16V on the signal, it can only effectively "read" up to about 6v.
It's also so complex I don't see how to make it work for a simple case!
I simply want the signal to trigger as "On" when I apply about 9V and off when there's no voltage.
But, the way it appears to work the "voltage ranges", the sensor shows the same state for "low" (below the threshold) as "high" (above the threshhold) voltages. Thus, 0 and 9 would both result in the same signal state (either on or off).
Unless I can, somehow, get those thresholds set to like "1" and "16V" (so that 0V is "outside" the range--while 9V is "inside" the range), I don't think the signal state will work as I need it to.
Thoughts?
I'm partially looking at this because I'm suspicious of Zooz devices wonking out my mesh. With no specific reason to think that.
these are the option.s there are no options for voltage that i can see.
just nc and no for the sensors
It seems the inputs and outputs can be entirely unrelated. I would like to have four nameable child devices. Rule maker allows for selection and use of each but the signal and the command are forced to share a name. Would it be feasible to have four independent child devices?
1 Like
The current Device handler for the MIMO2+ does have the inputs and outputs unrelated if you set the main device relay operation to manual. But it still only creates two devices.
The problem is the handler works the relays just fine but when the state changes in either of the sensor/inputs it does not register in Hubitat. I have asked Hubitat to look into it and it has been a black hole. I encourage you to try it and see if it works for you. Then you can let me know what I am doing wrong LOL. Within each child device there is a contact and a switch field. I can get the switch (relay) to work but when I cause the sensor (input) to register on the MIMO2+, the contact does not open/close in Hubitat.
Here is one of my prior posts. I think I have another as well:
The good news, and I highly recommend it, is the Zooz Zen16 multi relay with contacts just came out. It works exactly like the FortrezZ MIMO2+ but even has more features such as in the event of a power outage being able to have the relays go back to the last state they were in. Good for a water valve application in a house up in snow country when the power goes out!
Take a look. It is brand new and is being supported, unlike the FortrezZ which I think the company was sold and it is a fairly old part in the Zwave world. Close to the same form factor as well, which is nice if you have limited room and need to swap it out in a prior application. I have bench tested it last week and it works great with the built in device handler. Also has a cool feature of the relays being timed as well. (timed on OR timed off) very cool. But Hubitat forgot to make them configurable with the initial Device Handler. Though they were going to get that working too
I have three working cases of inputs to MIMO2+ doing control of other Z wave switches (not the MIMO relays). The inputs are connected to discreet contacts (not analog inputs). They are used by rules and appear in logs and dashboards. I have one MIMO Lite that uses input to direct relay. These all worked with default configuration so I can offer no advice, Have you tested the inputs by direct shorting with a jumper?
Thanks for the tip about the Zen17 ... checking that out next.
