Re: [mh] Need a working Z-Wave configuration

I don’t have any razberry ini entries, this is how I define the controller and items in the items.mht file:

RAZBERRY_CONTROLLER,	192.168.0.1,	razberry_controller,	zwave, push, user=adminuser,password=adminpass
RAZBERRY_COMM,		razberry_comm,	razberry_controller		
RAZBERRY_BLIND,		4, 	main_top_blinds, 	HVAC|zwave, 	razberry_controller

So the 4 maps to the ID #4 in the razberry interface

To get push working, you have to add in the HTTPGet module, with the configuration: 

URL to get: http://mhip:mhport/SUB;razberry_push(%DEVICE%,%VALUE%) <http://mhip:mhport/SUB;razberry_push(%25DEVICE%25,%25VALUE%25)>

Then any time the item changes state, the razberry system sends an update to MH. The push is much nicer than polling the razberry every few seconds.

I don’t think I got a special case, the HAT just fits in a standard case.

> On Dec 11, 2022, at 11:02 AM, Brian M <[email protected]> wrote:
> 
> Great! Would you please share the Razberry configuration that you use? I just need to see the *.ini  entries and one or two sample *.mht entries, comparable to mine below, so I can see if I missed  or messed up anything.
> 
> Also, if you have your RPi in a case, what case do you use that accommodates the razberry module?
> 
>                              -Brian M.
> 
> On 12/11/22 07:58, H Plato wrote:
>> Hi Brian, I have a working Z-wave setup, but not using the AEOTec Z-Stick. I have a razberry board plugged into the raspberry pi, and use webcalls back and forth. (There’s a razberry module in MH) Reliability is on-par with insteon for me. I control around 15 items, mainly blinds, locks and a few outdoor modules.
>> 
>>> On Dec 10, 2022, at 10:26 AM, Brian M <[email protected] <mailto:[email protected]>> wrote:
>>> 
>>> I'm hoping someone with a working Z-Wave configuration under MH will share their relevant configuration information with me, as I can't get mine to work.
>>> 
>>> Details:
>>> 
>>> I'm starting to dabble with Z-Wave under MH. I have an AEOTec Z-Stick (Gen5) plugged into my Raspberry Pi. I've tested the Z-stick using the Open Z-Wave control panel (ozwcp) installed and executed under the MH login. It can control my one Z-Wave light switch, so I know the Z-stick is good and the MH login has all the necessary permissions.
>>> 
>>> MH can't seem to connect to the Z-stick however. At start-up it attempts to send a reset to the Z-Stick, but fails.
>>> 
>>> I'm running the latest MH code pulled from the master branch (last update 10/29/2022).
>>> 
>>> In mh.private.ini I have:
>>> 
>>> ZWave_RZC0P_serial_port=/dev/ttyACM0
>>> rzc0p_errata=4
>>> rzc0p_retry_limit=5
>>> rzc0p_update10=0
>>> rzc0p_update100=1
>>> rzc0p_update1000=1
>>> rzc0p_timeout=10                      # Tried this at 60, no difference.
>>> rzc0p_id=001
>>> 
>>> In items.mht I have:
>>> 
>>> #Item Type              Zwave ID#       name            groups          interface       polling_interval        2way(1 or 0)    resume_level (if dimmer)
>>> ZWAVE_APPLIANCE,        006,            office_fan,     All_Lights,     ZWave_RZC0P,    7,                      0
>>> 
>>> Here's the log:
>>> 
>>> 12/10/22 09:15:52 AM ZWave_RZC0P Info: Specified retry_limit of 5
>>> 12/10/22 09:15:52 AM ZWave_RZC0P Info: Specified timeout of 10 seconds
>>>  to Zwave interfaceM ZWave_RZC0P Debug: Writing data >DE
>>> 12/10/22 09:15:52 AM ZWave_RZC0P ZWave_RZC0P error: ZWave interface timeout, cmd:>DE
>>> 12/10/22 09:15:52 AM ZWave_RZC0P ZWave_RZC0P error: data timeout
>>> 12/10/22 09:15:52 AM ZWave_RZC0P ZWave_RZC0P error: cmd timeout
>>> 12/10/22 09:15:52 AM Oops1: Use of uninitialized value in hash element at /home/mh/mh/bin/../lib/ZWave_RZC0P.pm line 420.
>>> 12/10/22 09:15:52 AM Oops1: Use of uninitialized value $upd_count in numeric gt (>) at /home/mh/mh/bin/../lib/ZWave_RZC0P.pm line 423.
>>> 12/10/22 09:15:52 AM Oops1: Use of uninitialized value in hash element at /home/mh/mh/bin/../lib/ZWave_RZC0P.pm line 429.
>>> 12/10/22 09:15:52 AM Oops1: Use of uninitialized value in numeric gt (>) at /home/mh/mh/bin/../lib/ZWave_RZC0P.pm line 429.
>>> 12/10/22 09:15:52 AM ZWave_RZC0P Adding id:006,type:ZWAVE_APPLIANCE,inst:0 to node list
>>> 12/10/22 09:15:52 AM ZWave_RZC0P Debug: Writing data >?N006 to Zwave interface
>>> 12/10/22 09:15:52 AM ZWave_RZC0P ZWave_RZC0P error: ZWave interface timeout, cmd:>?N006
>>> 12/10/22 09:15:52 AM ZWave_RZC0P ZWave_RZC0P error: data timeout
>>> 12/10/22 09:15:52 AM ZWave_RZC0P ZWave_RZC0P error: xmit timeout
>>> 12/10/22 09:15:52 AM ZWave_RZC0P ZWave_RZC0P error: cmd timeout
>>> 12/10/22 09:15:52 AM ZWave_RZC0P Info: Retrying Command >?N006, Retry Number:1 time:1670692573.43541
>>> 12/10/22 09:15:52 AM ZWave_RZC0P Debug: Writing data >?N006 to Zwave interface
>>> 12/10/22 09:15:52 AM ZWave_RZC0P ZWave_RZC0P error: ZWave interface timeout, cmd:>?N006
>>> 12/10/22 09:15:52 AM ZWave_RZC0P ZWave_RZC0P error: data timeout
>>> 12/10/22 09:15:52 AM ZWave_RZC0P ZWave_RZC0P error: xmit timeout
>>> 12/10/22 09:15:52 AM ZWave_RZC0P ZWave_RZC0P error: cmd timeout
>>> 12/10/22 09:15:52 AM ZWave_RZC0P Was in Zwave check_for_data sub for 10.0004432201385 seconds
>>> 
>>> The Oops1 errors are in the timeout handler, so they probably wouldn't happen if the timeout didn't occur. The simple problem is that the initial send is timing out. 
>>> 
>>> It's probably something simple, like needing to declare a baud rate (which baud and how) or something similar. Do I need to run setserial first? Can anyone put me on the right track?
>>> 
>>>                                            -Brian M
>>> 
>>> 
>>> ________________________________________________________
>>> To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users <https://lists.sourceforge.net/lists/listinfo/misterhouse-users>
>>> 
>> 
>

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users