Did you take a look at my log from the post above… Aeon Labs Minimote help (Resolved) This should show you what I was getting when I was trying to do this the first time. I finally got the minimote working and my wife and kids use it now but if you really need me to I can “break” it to get a log again but I’ll be quite busy for the next week or so.
@Qris - have you tried to factory reset your minimote and start it over? Also, your screenshot of ozwcp looks quite different than mine did when I did this so I wonder if maybe you are using a different version. I did have an instance when I was testing this where I couldn’t get the options to come up correctly on a machine running ozwcp but then I tried on another computer and it did come up. I’m not sure what the difference was though.
Nope - I didn’t spot it - sorry. I didn’t read through the complete thread, but just had a look through the log. It looks like the device might not be responding to one of the STATIC messages as mentioned earlier - it might just be a one off, but it would be good to see if it stops in the same place each time.
Given this is a battery device, this continual timeout might then be the reason it’s not possible to set the configuration parameter. Can you provide a new log from startup until it stops again - I want to see a few other things, as well as where it stops… If it shows the same issue, I can look at adding something in the database to configure this.
I don’t have a log to hand – can anyone send Chris a log of what happens when you wake up a minimote (and it fails to initialize)?
As to the sending commands to initialized devices, I have many battery powered devices, and you cannot send (configuration) commands to them until they have finished initialization, and have serialized to a file. I’m sure you know this binding well, but I can absolutely confirm that this is the case. You may be able to send commands to devices that have not initialized, if they have previously initialized (and serialized to a file), but if they have never initialized (and have no .xml file) you can’t sent configuration commands to them.
This may just be because the wake up queue is full of “CONFIGURATION_GET” requests, which then get reset after too many retries.
Once you see the magic words “serializing to file /var/…….” In the log, then you can change things in habmin (you have to keep waking the device up, but it will work). Before those magic words, the values in habmin stay yellow, and are not updated on the device, no matter how many times you wake it up.
If no-one else comes up with one, I’ll see what I can do about a log. It would be nice to have the minimote initialize, configuration would be easy, and I could name it properly.
Regards,
Nick Waterton P.Eng.
National Support Leader - Nuclear Medicine, PET and RP
GE Healthcare
If no one comes up with a log in a day or so I can grab one. I currently have my MiniMote on my Vera as it wasn’t usable under OH, could never seem to get the timing right for the unit to send OH anything, also tried w/ open-zwave to get it into the right mode but that was unsuccessful as well. It was just easier to drop it on the Vera and use the Mios binding.
I can take one for the team though and switch it over to my OH test bed to grab some logs if needed. Let me know.
I have created a log. Also a screenshot of what fills in in habmin after attempting to initialize the minimote. They are here:
Note: you have to press the “Learn” button for at least 3 second to wake the minimote up, a momentary press doesn’t do it. This is repeatedly pressing “Learn” then waiting, the minimote wakes up, then goes to sleep. Press “Learn” again, minimote wakes up - goes to sleep. Initialization never completes.
Nick Waterton P.Eng.
National Support Leader - Nuclear Medicine, PET and RP
GE Healthcare
Thanks - this confirms (very well, and numerous times ) what I saw in the previous log. So, I think that the device isn’t responding to the message to get the wakeup information, and this timeout is stopping other messages being sent…
It will take a small amount of work to resolve this - I’ll take a look…
Or ‘read-only’ even… It seems you pretty much can’t read anything from this device .
I see you uploaded the XML - it would be worth updating the database with all the write-only tags. I need to work out how to handle the scene class in the database - I’ll look at that over the next few days…
I was going to ask you about that. What would be the correct way to handle this in ESH anyway? The mapping of scene activation to a switch always seemed like a hack in OH1.
Yes, well, for now I was going to use the same hack as it’s going to be the quickest option… However, I do agree that there’s no good concept for triggering scenes - this is something that probably should be raised in the ESH forum. It might be possible with the new rule system to do something a bit ‘nicer’ by directly linking to a rule?
As a coda (and for anyone running across this thread via google; I re-stumbled upon this thread via an unrelated search), there’s a reliable way to get minimotes working in OH with no additional software required.
rule “zwave test button 1”
when
Rem_A_b1m received update
then
sendCommand(Toggle_3, ON)
end
I know that the topic is old but you pointed me in the right direction to solve my issue so I will point out that your rule was missing an “Item” after the when, that’s why your rule wasn’t working!
the working rule should be
rule “zwave test button 1”
when
Item Rem_A_b1m received update
then
sendCommand(Toggle_3, ON)
end
yes, I pointed it out only because you wrote “I’m not sure exactly what the
problem was” so now you know that the problem was the keyword "Item"
missing in your rule!
Hello 18 months later.
I am not able to set parameter 250 via open zwave control panel because it seemingly never populates node 25’s (my minimote) configuration. I’ve been reading, probing, tinkering, etc. I’m open to any/all thoughts and suggestions, please. My hope is that I can finally set parameter 250 to scene mode so OpenHab 2.3 can trap the button traffic. I’ve tried waking my minimote about 3.14 million times.
I stopped the OpenHab service before running ozwcp.
I have a new install of OH2.3, Raspberry Pi 3 with Debian jessie, Aeotec Z-stick, and just installed Open Zwave and its control panel [seemingly] fine, including the microhttpd.
This is what I see after 1 hour of clicking initialize and waking the remote ever few minutes. What should I do next, please?
Lastly, is this a known issue in the OH2.3 Zwave Binding?
tocol.commandclass.ZWaveCommandClass] - NODE 25: Unsupported command class ASSOCIATION_COMMAND_CONFIGURATION
==> /var/log/openhab2/events.log <==
2018-06-25 21:37:47.735 [me.event.ThingUpdatedEvent] - Thing ‘zwave:device:f21702b0:node25’ has been updated.
==> /var/log/openhab2/openhab.log <==
2018-06-25 21:37:47.711 [WARN ] [tocol.commandclass.ZWaveCommandClass] - NODE 25: Unsupported command class ASSOCIATION_COMMAND_CONFIGURATION
==> /var/log/openhab2/events.log <==
2018-06-25 21:37:47.735 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:f21702b0:node25' has been updated.
Thank you, all. I do have firmware 1.19 (current to date). I managed to finally set the parameter 250 via another way, and sure enough the Minimote then worked as expected. I’ll reach out to open zwave support later.
) what I saw in the previous log. So, I think that the device isn’t responding to the message to get the wakeup information, and this timeout is stopping other messages being sent…
.
.
,