profile
viewpoint

CWSpear/angular-form-errors-directive 29

A directive for AngularJS that displays a nice list of errors for a form.

CWSpear/angular-menu-slideout 27

A high performance Angular directive for sliding out an offscreen menu on swipe.

CWSpear/angular-postman 9

A Growl/OSX Notification Center/toastr inspired pure-Angular way to do simple, global notifications.

CWSpear/Active-Record-Database-Helper 3

A simple active record database helper that I wrote to basically implement some of the most common functions I use form the CodeIgniter docs.

CWSpear/3d-print-designer 1

My pipeline for programmatically designing 3D print files

CWSpear/awesome-list 1

A set of AngularJS directives for a reusable filtering, sorting & paginating list without the need of controller logic.

CWSpear/Community-Icon-Font 1

To create a collaborative font using SVG

CWSpear/angular-common 0

A group of common angular modules I use on most every project.

CWSpear/angular-seed 0

:seedling: A simple Angular seed featuring Angular 2 (or Angular 4) and Webpack 2 by @AngularClass

CWSpear/angular-seo 0

SEO for AngularJS apps made easy.

startedevanw/esbuild

started time in 18 days

issue commentMatchbookLab/local-persist

WSL Plugin not found / registered

It's not a matter of just having the sock in plugins, you have to have the container running and it has to have access to the sock:

docker run -d \
    --name local-persist \
    -v /run/docker/plugins/:/run/docker/plugins/ \
    -v /data/:/data/ \
    -v /CHANGE_THIS_PATH/:/var/lib/docker/plugin-data/ \
        cwspear/docker-local-persist-volume-plugin

In that case, since you named it local-persist, you can check logs to make sure it's running ok:

docker logs local-persist

You can add a -f after logs to have it follow the logs so you can see what the output is while you try to create a volume.

I haven't tested this in WSL, so your mileage may vary.

InvenTorrey

comment created time in 2 months

startedraineorshine/npm-check-updates

started time in 2 months

startedPop-Code/nestjs-console

started time in 2 months

startedcustom-cards/boilerplate-card

started time in 3 months

issue closedjeubanks/hubitat-mqtt-bridge

Events sent to Locks don't seem to work

I can see that hubitat/Front Door Lock/lock = unlock is getting published when I trigger it in Home Assistant, but the lock is still locked.

Updates from Hubitat to Home Assistant work (unlocking it manually).

This is my Lock config:

- platform: mqtt
  name: Front Door Lock
  state_topic: hubitat/Front Door Lock/lock
  command_topic: hubitat/Front Door Lock/lock
  payload_lock: locked
  payload_unlock: unlocked
  state_locked: locked
  state_unlocked: unlocked
  optimistic: false
  qos: 1
  retain: true

I have a Schlage BE468/BE469 Lock.

When I press it in Home Assistant, I can see it in the MQTT Bridge Device Event log:

{"name":"Front Door Lock","type":"lock","value":"unlocked","command":true}

So I know the MQTT command is getting the event... it's a breakdown somewhere between there and actually unlocking the door (e.g. either the Zwave command isn't even being called, or else it's being rejected).

It does not work to unlock nor lock the door.

closed time in 3 months

CWSpear

issue commentjeubanks/hubitat-mqtt-bridge

Events sent to Locks don't seem to work

Ok, so the App is looking for lock and unlock payloads, whereas the event for when it un/locks is locked and unlocked, so this change:

-  payload_lock: locked
-  payload_unlock: unlocked
+  payload_lock: lock
+  payload_unlock: unlock

with the final result of:

- platform: mqtt
  name: Front Door Lock
  state_topic: hubitat/Front Door Lock/lock
  command_topic: hubitat/Front Door Lock/lock
  payload_lock: lock
  payload_unlock: unlock
  state_locked: locked
  state_unlocked: unlocked
  optimistic: false
  qos: 1
  retain: true

made it work.

I was coming from SmartThings, which uses unlocked/locked for both the state and payload, which is why I was confident it should have worked! :)

If we really wanted to be thorough, we could make the app support both with and without ed for the command... but the way you have it also makes sense (I think since the property is called payload_lock, that lock is probably even the default... if I'd just done nothing in terms of defining the payload/state, it probably would have worked!)

CWSpear

comment created time in 3 months

issue openedjeubanks/hubitat-mqtt-bridge

Events sent to Locks don't seem to work

I can see that hubitat/Front Door Lock/lock = unlock is getting published when I trigger it in Home Assistant, but the lock is still locked.

Updates from Hubitat to Home Assistant work (unlocking it manually).

This is my Lock config:

- platform: mqtt
  name: Front Door Lock
  state_topic: hubitat/Front Door Lock/lock
  command_topic: hubitat/Front Door Lock/lock
  payload_lock: locked
  payload_unlock: unlocked
  state_locked: locked
  state_unlocked: unlocked
  optimistic: false
  qos: 1
  retain: true

I have a Schlage BE468/BE469 Lock.

When I press it in Home Assistant, I can see it in the MQTT Bridge Device Event log:

{"name":"Front Door Lock","type":"lock","value":"unlocked","command":true}

So I know the MQTT command is getting the event... it's a breakdown somewhere between there and actually unlocking the door (e.g. either the Zwave command isn't even being called, or else it's being rejected).

It does not work to unlock nor lock the door.

created time in 3 months

issue commentOpenZWave/Zwave2Mqtt

[bug] Dimmer won't turn off in Home Assisstant UI

Ok, so I was investigating it more on the z2m side.

For example, if I'm at Level 13, and I try to go to 55 via the z2m interface, e.g. change the value to 55 and hit the submit button:

Screen Shot 2020-07-31 at 5 27 39 PM

And try to capture what happens in the logs, I see this:

z2m:App Zwave api call: setValue [ 30, 38, 1, 0, '55' ] +27s
z2m:Zwave Success zwave api call setValue +26s
OpenZWave Info, Node030, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 - 55
OpenZWave Info, Node030, SwitchMultilevel::Set - Setting to level 55
OpenZWave Detail, Node030, Queuing (Send) SwitchMultilevelCmd_Set (Node=30): 0x01, 0x0a, 0x00, 0x13, 0x1e, 0x03, 0x26, 0x01, 0x37, 0x25, 0x71, 0xbf
OpenZWave Detail, Node030, Queuing (Send) SwitchMultilevelCmd_Get (Node=30): 0x01, 0x09, 0x00, 0x13, 0x1e, 0x02, 0x26, 0x02, 0x25, 0x72, 0x8a
OpenZWave Detail,
OpenZWave Info, Node030, Sending (Send) message (Callback ID=0x71, Expected Reply=0x13) - SwitchMultilevelCmd_Set (Node=30): 0x01, 0x0a, 0x00, 0x13, 0x1e, 0x03, 0x26, 0x01, 0x37, 0x25, 0x71, 0xbf
OpenZWave Info, Node030, Encrypted Flag is 0
OpenZWave Detail, Node030, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
OpenZWave Detail, Node030, ZW_SEND_DATA delivered to Z-Wave stack
OpenZWave Detail, Node030, Received: 0x01, 0x07, 0x00, 0x13, 0x71, 0x00, 0x00, 0x02, 0x98
OpenZWave Detail, Node030, ZW_SEND_DATA Request with callback ID 0x71 received (expected 0x71)
OpenZWave Info, Node030, Request RTT 23 Average Request RTT 23
OpenZWave Detail, Node030, Expected callbackId was received
OpenZWave Detail, Node030, Expected reply was received
OpenZWave Detail, Node030, Message transaction complete
OpenZWave Detail,
OpenZWave Detail, Node030, Removing current message
OpenZWave Detail,
OpenZWave Info, Node030, Sending (Send) message (Callback ID=0x72, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=30): 0x01, 0x09, 0x00, 0x13, 0x1e, 0x02, 0x26, 0x02, 0x25, 0x72, 0x8a
OpenZWave Info, Node030, Encrypted Flag is 0
OpenZWave Detail, Node030, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
OpenZWave Detail, Node030, ZW_SEND_DATA delivered to Z-Wave stack
OpenZWave Detail, Node030, Received: 0x01, 0x07, 0x00, 0x13, 0x72, 0x00, 0x00, 0x02, 0x9b
OpenZWave Detail, Node030, ZW_SEND_DATA Request with callback ID 0x72 received (expected 0x72)
OpenZWave Info, Node030, Request RTT 25 Average Request RTT 24
OpenZWave Detail, Node030, Expected callbackId was received
OpenZWave Detail, Node030, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x1e, 0x03, 0x26, 0x03, 0x0d, 0xc7
OpenZWave Detail,
z2m:Zwave zwave node 30: changed: 38-1-0:Level:13 -> 13 +62ms
OpenZWave Info, Node030, Response RTT 36 Average Response RTT 35
OpenZWave Info, Node030, Received SwitchMultiLevel report: level=13
OpenZWave Detail, Node030, Value Updated: old value=13, new value=13, type=byte
OpenZWave Detail, Node030, Changes to this value are verified
OpenZWave Detail, Node030, Expected reply and command class was received
OpenZWave Detail, Node030, Message transaction complete
OpenZWave Detail,
OpenZWave Detail, Node030, Removing current message

It immediately sets it back to 13. And in the UI, (e.g. screenshot above), it immediately changes back to 13. But the lights actually change to 55. And if I change it to 55 again and do it, it of course works.

It doesn't do this every time, but it does do it most times.

I updated the Firmware just to be case, and then removed/added the device, but it didn't make a difference.

Device: HS-WD100+ Wall Dimmer from HomeSeer Firmware (aka Application) Version: 5.19 Procol Version: 4.34 Library Version: 3 OpenZWave Version: 1.6.1210 ZWave2MQTT Version: latest Docker tag as of today

Specifically... it doesn't seem like an issue with z2m as maybe openzwave in general? (Or of course, it could be the Switch or the Z-Stick I'm using (Aeotec Z-Stick Gen5), but other hubs (SmartThings, Hubitat) seem to handle it just fine.)

CWSpear

comment created time in 3 months

issue commentOpenZWave/Zwave2Mqtt

[bug] Dimmer won't turn off in Home Assisstant UI

When I manually press up or down on the paddle, I get a bunch of updates and everything works fine.

If the light is on full brightness and I turn it off via the paddle, this is my logs:

[Debug] zwave/office_lights/91/1/2 = {"time":1596135708400,"value":1}
[Debug] zwave/office_lights/91/1/2 = {"time":1596135709400,"value":0}
[Debug] zwave/office_lights/38/1/0 = {"time":1596135711371,"value":0}
[Debug] zwave/office_lights/38/1/0 = {"time":1596135711408,"value":0}
[Debug] zwave/office_lights/38/1/0 = {"time":1596135711412,"value":0}
[Debug] zwave/office_lights/38/1/1 = {"time":1596135711412}
[Debug] zwave/office_lights/38/1/2 = {"time":1596135711412}
[Debug] zwave/office_lights/38/1/3 = {"time":1596135711412,"value":true}
[Debug] zwave/office_lights/38/1/4 = {"time":1596135711413,"value":0}
[Debug] zwave/office_lights/39/1/0 = {"time":1596135711413,"value":3}
[Debug] zwave/office_lights/43/1/0 = {"time":1596135711413,"value":0}
[Debug] zwave/office_lights/43/1/1 = {"time":1596135711413,"value":0}
[Debug] zwave/office_lights/91/1/1 = {"time":1596135711413,"value":0}
[Debug] zwave/office_lights/91/1/2 = {"time":1596135711413,"value":0}
[Debug] zwave/office_lights/91/1/256 = {"time":1596135711413,"value":2}
[Debug] zwave/office_lights/91/1/257 = {"time":1596135711413,"value":1000}
[Debug] zwave/office_lights/94/1/0 = {"time":1596135711413,"value":1}
[Debug] zwave/office_lights/94/1/1 = {"time":1596135711413,"value":1536}
[Debug] zwave/office_lights/94/1/2 = {"time":1596135711413,"value":1536}
[Debug] zwave/office_lights/112/1/4 = {"time":1596135711413,"value":0}
[Debug] zwave/office_lights/112/1/7 = {"time":1596135711413,"value":99}
[Debug] zwave/office_lights/112/1/8 = {"time":1596135711413,"value":22}
[Debug] zwave/office_lights/112/1/9 = {"time":1596135711413,"value":99}
[Debug] zwave/office_lights/112/1/10 = {"time":1596135711413,"value":22}
[Debug] zwave/office_lights/114/1/0 = {"time":1596135711413,"value":8}
[Debug] zwave/office_lights/114/1/1 = {"time":1596135711413,"value":8}
[Debug] zwave/office_lights/114/1/2 = {"time":1596135711413,"value":8}
[Debug] zwave/office_lights/115/1/0 = {"time":1596135711413,"value":0}
[Debug] zwave/office_lights/115/1/1 = {"time":1596135711413,"value":0}
[Debug] zwave/office_lights/115/1/2 = {"time":1596135711413}
[Debug] zwave/office_lights/115/1/3 = {"time":1596135711413,"value":0}
[Debug] zwave/office_lights/115/1/4 = {"time":1596135711414,"value":0}
[Debug] zwave/office_lights/115/1/5 = {"time":1596135711414,"value":0}
[Debug] zwave/office_lights/115/1/6 = {"time":1596135711414}
[Debug] zwave/office_lights/115/1/7 = {"time":1596135711414}
[Debug] zwave/office_lights/115/1/8 = {"time":1596135711414,"value":0}
[Debug] zwave/office_lights/115/1/9 = {"time":1596135711414,"value":0}
[Debug] zwave/office_lights/134/1/0 = {"time":1596135711414,"value":"3"}
[Debug] zwave/office_lights/134/1/1 = {"time":1596135711414,"value":"4.34"}
[Debug] zwave/office_lights/134/1/2 = {"time":1596135711414,"value":"5.17"}

So yeah. Everything works fine if I update via the actual physical paddle. As I move stuff around it shows the correct values in Home Assistant. It's just updating via Home Assistant that I get this.

I noticed that it also doesn't do a /set call if I press the paddle. Just that I hit "up" basically.

CWSpear

comment created time in 3 months

issue commentOpenZWave/Zwave2Mqtt

[bug] Dimmer won't turn off in Home Assisstant UI

In a little further testing, I don't always get the final value when turning them on either.

Turning them on, I just got this:

[Debug] zwave/office_lights/38/1/0/set = 255
[Debug] zwave/office_lights/38/1/0 = {"time":1596129630538,"value":14}

But it should have turned it on to 99 (and that's what the lights are at: 99% brightness). The UI incorrectly reports 14%.

CWSpear

comment created time in 3 months

issue commentOpenZWave/Zwave2Mqtt

[bug] Dimmer won't turn off in Home Assisstant UI

I can see from other comments, you don't use Home Assistant. It seems like this may be an issue when Zwave2Mqtt specifically, tho, in that it is sending the update of its level too soon instead of waiting until it reached it's destination or something alone those lines...

If I turn it on, I don't get the update of the brightness value until after it's reached the target value a second or so later:

mqtt-bridge_1              | 2020-07-30T16:47:58.987264351Z Dbug: zwave/office_lights/38/1/0/set = 255
mqtt-bridge_1              | 2020-07-30T16:48:00.530956434Z Dbug: zwave/office_lights/38/1/0 = {"time":1596127680530,"value":48}

Contrast that with when I turn it off, it reports it's state immediately after getting the call to change it to zero, even tho the light hasn't had time to actually change.

(I assume just turning it out has it call it with 255, but it does set it to 48, which was the previous brightness I had. Not sure what that's about.)

CWSpear

comment created time in 3 months

issue openedOpenZWave/Zwave2Mqtt

[bug] Dimmer won't turn off in Home Assisstant UI

Version

Build/Run method

  • [x] Docker
  • [ ] PKG
  • [ ] Manually built (git clone - npm install - npm run build )

Zwave2Mqtt version: I don't know... latest tag from Docker as of 29 July 2020 at ~10pm PDT. Openzwave Version: 1.6.1210

(I couldn't find a version for Zwave2Mqtt... might be nice to have one in the app somewhere like Openzwave's version is)

Describe the bug

If the light is on at say 48 brightness, when I turn off the light in Home Assistant, I sometimes get this (which is expected):

(This is from logs dumping my MQTT messages for debugging. zwave is my prefix.)

2020-07-30T08:27:38.593049351Z [Debug] zwave/office_lights/38/1/0/set = 0
2020-07-30T08:27:39.435080555Z [Debug] zwave/office_lights/38/1/0 = {"time":1596097659434,"value":0}

It works fine when this happens.

But more often than not, this is what happens:

2020-07-30T08:27:52.001829759Z [Debug] zwave/office_lights/38/1/0/set = 0
2020-07-30T08:27:52.065765754Z [Debug] zwave/office_lights/38/1/0 = {"time":1596097672064,"value":48}

(Notice the timestamps: it usually updates the state before it's even started to turn off, which becuase the dimmers I have (HomeSeer WD-100+) transition to off.)

That causes Home Assistant to show the light as on, even tho the lights are off, and I have to toggle them off and then back on again to actually turn them on.

This is what it looks like in the UI:

Dimmer Issue

Note that the lights are on in the office at the start of the video, and they are off at the end, even tho the toggle shows they are on.

To Reproduce Steps to reproduce the behavior:

  1. Add a dimmer that transitions to target brightness (e.g. HomeSeer WD-100+).
  2. Add it to Home Assistant via MQTT discovery.
  3. Turn the light on in Home Assistant. Turn it off, then on. Next time you turn it off, you should trigger this issue.

Expected behavior Home Assistant should show that the light is off.

Actual behavior Home Assistant shows that the light is on, even tho the light is actually off.

created time in 3 months

startedOpenZWave/Zwave2Mqtt

started time in 3 months

startedjeubanks/hubitat-mqtt-bridge

started time in 3 months

more