Charmed Quark Systems, Ltd. - Support Forums and Community

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82

Reset the trace and do the unit query, then stop it and send me that output. It sounds like it's not responding to the CC version queries despite the fact that it reports supporting the version CC.

The above messages are just node info messages. Why on earth it sends that every time you press a button I have no idea. That's completely wasteful. We see it because it's broadcast, so no associations required.

(06-08-2018, 09:29 PM)Dean┬áRoddey Wrote: [ -> ]Reset the trace and do the unit query, then stop it and send me that output. It sounds like it's not responding to the CC version queries despite the fact that it reports supporting the version CC.

The above messages are just node info messages. Why on earth it sends that every time you press a button I have no idea. That's completely wasteful. We see it because it's broadcast, so no associations required.

This is what shows up in the trace when doing a "Query Unit Info"
Z-Wave USB3 Trace
,┬á Time: 9:12:12 AM
----------------------------------------------------

09:12:18 - [TRACE]- Waiting for unit=1D, msg=49, class=None, ccmd=Unknown
09:12:18 - Sending a new msg:
{
┬á ┬á [DR->ZW] - (REQ,Msg: ReqNodeInfo/0x60,AckId=12597)┬á
┬á ┬á {
┬á ┬á ┬á ┬á Bytes: 04 00 60 1D┬á
┬á ┬á }
}
09:12:18 - [TRACE]- Sending msg, AckId=12597, Attempt #1
09:12:18 - [TRACE]- Transitioned from Idle to WaitAck state
09:12:18 - [ZW->DR] - ACK
09:12:18 - [TRACE]- Transitioned from WaitAck to Idle state
09:12:18 - [ZW->DR] - RES,Msg:ReqNodeInfo/0x60,Recvd: 09:12:18) 4MSs
{
┬á ┬á Bytes: 01┬á
}

Dean,
on the WebRiva client is there a way to scale the template? Would like to run my iPad templates on android chrome but they are way too small.. if I use the below they are way to big and you cannot scroll around. They don't need to fit perfectly but didn't want to make a set of templates for each phone resolution.
Even if something as simple as the ability to set the scaling size? ie (pixelscale=1)┬á probably only need scaling 1 to 5 or so.

nopixelscale=1". By default, the client will set the view scaling so that it undoes any default scaling done by the device. This allows you to create templates the same size as your device's resolution and have them fit. Often the devices have a default 'pixel ratio' or 2 or more (meaning 1 pixels of the original becomes 2x2 pixels as displayed.) If you don't want this and want to let it size up the contents, this option will allow that.

WebRiva is very solid now... Thanks again.
Kevin

(06-09-2018, 05:19 AM)kfly Wrote: [ -> ]
(06-08-2018, 09:29 PM)Dean┬áRoddey Wrote: [ -> ]Reset the trace and do the unit query, then stop it and send me that output. It sounds like it's not responding to the CC version queries despite the fact that it reports supporting the version CC.

The above messages are just node info messages. Why on earth it sends that every time you press a button I have no idea. That's completely wasteful. We see it because it's broadcast, so no associations required.

This is what shows up in the trace when doing a "Query Unit Info"
Z-Wave USB3 Trace
,┬á Time: 9:12:12 AM
----------------------------------------------------

09:12:18 - [TRACE]- Waiting for unit=1D, msg=49, class=None, ccmd=Unknown
09:12:18 - Sending a new msg:
{
┬á ┬á [DR->ZW] - (REQ,Msg: ReqNodeInfo/0x60,AckId=12597)┬á
┬á ┬á {
┬á ┬á ┬á ┬á Bytes: 04 00 60 1D┬á
┬á ┬á }
}
09:12:18 - [TRACE]- Sending msg, AckId=12597, Attempt #1
09:12:18 - [TRACE]- Transitioned from Idle to WaitAck state
09:12:18 - [ZW->DR] - ACK
09:12:18 - [TRACE]- Transitioned from WaitAck to Idle state
09:12:18 - [ZW->DR] - RES,Msg:ReqNodeInfo/0x60,Recvd: 09:12:18) 4MSs
{
┬á ┬á Bytes: 01┬á
}

Did you stop or flush the trace? It doesn't look like you did, so you didn't get any actual trace content. If that's all that really happened, then it's not responding at all. I assumed this guy is not battery powered but wall powered?

(06-09-2018, 07:00 AM)kfly Wrote: [ -> ]Dean,
on the WebRiva client is there a way to scale the template? Would like to run my iPad templates on android chrome but they are way too small.. if I use the below they are way to big and you cannot scroll around. They don't need to fit perfectly but didn't want to make a set of templates for each phone resolution.
Even if something as simple as the ability to set the scaling size? ie (pixelscale=1)┬á probably only need scaling 1 to 5 or so.

nopixelscale=1". By default, the client will set the view scaling so that it undoes any default scaling done by the device. This allows you to create templates the same size as your device's resolution and have them fit. Often the devices have a default 'pixel ratio' or 2 or more (meaning 1 pixels of the original becomes 2x2 pixels as displayed.) If you don't want this and want to let it size up the contents, this option will allow that.

WebRiva is very solid now... Thanks again.
Kevin

I think I may have misunderstood the scaling thing. I'm going to try something different for the next drop to see if that is so.

(06-09-2018, 08:30 AM)Dean┬áRoddey Wrote: [ -> ]Did you stop or flush the trace? It doesn't look like you did, so you didn't get any actual trace content. If that's all that really happened, then it's not responding at all. I assumed this guy is not battery powered but wall powered?

OK Looks like I tested the wrong unit last time Sad

... Not sure why I decided to make it harder and switch to testing┬áUnit_1D and and not Unit_1A....

I did an update controller from the vizia RF+ stick and looks like we get more back.
So here is the "real" trace of the "Query Unit Info"┬á .. that returns "Could not get the version for CC Association"
(┬áLeviton┬á VRCZ4-M0Z 4-Button Zone Controller (wall switch))

Z-Wave USB3 Trace

,┬á Time: 5:24:05 PM
----------------------------------------------------

17:24:11 - [TRACE]- Waiting for unit=1A, msg=49, class=None, ccmd=Unknown
17:24:11 - Sending a new msg:
{
┬á ┬á [DR->ZW] - (REQ,Msg: ReqNodeInfo/0x60,AckId=14414)┬á
┬á ┬á {
┬á ┬á ┬á ┬á Bytes: 04 00 60 1A┬á
┬á ┬á }
}
17:24:11 - [TRACE]- Sending msg, AckId=14414, Attempt #1
17:24:11 - [TRACE]- Transitioned from Idle to WaitAck state
17:24:11 - [ZW->DR] - ACK
17:24:11 - [TRACE]- Transitioned from WaitAck to Idle state
17:24:11 - [ZW->DR] - RES,Msg:ReqNodeInfo/0x60,Recvd: 17:24:11) 4MSs
{
┬á ┬á Bytes: 01┬á
}
17:24:11 - [ZW->DR] - REQ,Msg:AppUpdate/0x49,Recvd: 17:24:11) 29MSs
{
┬á ┬á Type: Node Info
┬á ┬á SrcId: 1A
┬á ┬á GenType: GenCtrl
┬á ┬á SpecType: 0
┬á ┬á Classes: Association 2D 7C Naming 82 PowerLev Version ManSpec 91 EF SceneAct SceneActConf
┬á ┬á Bytes: 84 1A 0F 02 01 00 85 2D 7C 77 82 73 86 72 91 EF 2B 2C┬á
}
17:24:11 - [TRACE]- Got expected reply
17:24:11 - [TRACE]- Waiting for unit=1A, msg=4, class=ManSpec, ccmd=Report
17:24:12 - Sending a new msg:
{
┬á ┬á [DR->ZW] - (REQ,Msg: SendData/0x13,AckId=14415,CBId=217) 43MSs
┬á ┬á {
┬á ┬á ┬á ┬á TarId: 1A
┬á ┬á ┬á ┬á Class: ManSpec
┬á ┬á ┬á ┬á ┬áCmd: Get
┬á ┬á ┬á ┬á Bytes: 09 00 13 1A 02 72 04 24 D9┬á
┬á ┬á }
}
17:24:12 - [TRACE]- Sending msg, AckId=14415, Attempt #1
17:24:12 - [TRACE]- Transitioned from Idle to WaitAck state
17:24:12 - [ZW->DR] - ACK
17:24:12 - [TRACE]- Transitioned from WaitAck to WaitCallback state
17:24:12 - [ZW->DR] - RES,Msg:SendData/0x13,Recvd: 17:24:12) 4MSs
{
┬á ┬á Bytes: 01┬á
}
17:24:12 - [ZW->DR] - TRANSACK,Msg:SendData/0x13,Recvd: 17:24:12) 9MSs
{
┬á ┬áCallback Id: 217
┬á ┬á ┬á ┬á Status: Success
┬á ┬á Bytes: D9 00 00 01┬á
}
17:24:12 - [TRACE]- Transitioned from WaitCallback to Idle state
17:24:12 - [ZW->DR] - REQ,Msg:AppCmd/0x4,Recvd: 17:24:12) 41MSs
{
┬á ┬á Flags:
┬á ┬á Type: Single
┬á ┬á SrcId: 1A
┬á ┬á Class: ManSpec
┬á ┬á ┬áCmd: Report
┬á ┬á ManId: 1D
┬á ┬á TypeId: 702
┬á ┬á ProdId: 261
┬á ┬á Maps To: Unknown
┬á ┬á Bytes: 00 1A 08 72 05 00 1D 07 02 02 61┬á
}
17:24:12 - [TRACE]- Processing app cmd. Src=1A, Class=72, Cmd=5
17:24:12 - [TRACE]- Got expected reply
17:24:12 - [TRACE]- Waiting for unit=1A, msg=4, class=Version, ccmd=Report
17:24:12 - Sending a new msg:
{
┬á ┬á [DR->ZW] - (REQ,Msg: SendData/0x13,AckId=14416,CBId=218) 42MSs
┬á ┬á {
┬á ┬á ┬á ┬á TarId: 1A
┬á ┬á ┬á ┬á Class: Version
┬á ┬á ┬á ┬á ┬áCmd: Get
┬á ┬á ┬á ┬á Bytes: 0A 00 13 1A 03 86 13 85 24 DA┬á
┬á ┬á }
}
17:24:12 - [TRACE]- Sending msg, AckId=14416, Attempt #1
17:24:12 - [TRACE]- Transitioned from Idle to WaitAck state
17:24:12 - [ZW->DR] - ACK
17:24:12 - [TRACE]- Transitioned from WaitAck to WaitCallback state
17:24:12 - [ZW->DR] - RES,Msg:SendData/0x13,Recvd: 17:24:12) 3MSs
{
┬á ┬á Bytes: 01┬á
}
17:24:12 - [ZW->DR] - TRANSACK,Msg:SendData/0x13,Recvd: 17:24:12) 10MSs
{
┬á ┬áCallback Id: 218
┬á ┬á ┬á ┬á Status: Success
┬á ┬á Bytes: DA 00 00 01┬á
}
17:24:12 - [TRACE]- Transitioned from WaitCallback to Idle state

Looks like it just never replied. It responded to other things, so it's not like comms aren't good. I dunno, maybe just another flakey implementation.

Oh, it's disabled because it reports itself as a controller. We disable controllers since we don't need anything from them. But it's a controller in the scene controller sense. So that means we need to look at the specific type and only disable master and secondary type controllers, not scene controllers. That such because I don't think I'm even keeping the specific type around. I'll have to look at that.

So I've been trying to move some more things over to my recently created publish/subscribe scheme, since it has a lot of advantages. I kept having issues and would try thing and that and then this and that, but it was always kind of wonky. Finally the obvious dawned on me that the async nature of it means that if you are using it to keep one thing in sync with another, and it is based on indices, then if two things happen before the first one gets seen by the subscriber, then the indices could be off.

After a few bungled attempts to get around that, I realized that what I really needed to do was to make the fundamental subscriber scheme just a mixin interface that is called synchronously. That is fine for a lot of stuff, particularly GUI stuff, and where there's only one thread and you want to be sure that any changes are processed before more changes can occur. It does mean each subscriber of a topic gets called synchronously one at a time, so they have to be quick. Or figure out the changes required, before things change, store that, and return.

Then I could build the same async style subscriber on top of that by just making my old subscriber guy implement the mixin class, and just store the incoming msgs away for later retrieval. So it's straightforward to support both types.

That then meant that a single subscriber has to be able to subscribe to multiple topics, whereas before you'd just create multiple subscriber objects, one per topic. Since it happens via mixin with a single callback method now, subscribing to multiple topics is all in one subscriber instance. So that was another big change.

I've just now about got it back going again, after like three days. But, it'll pay off down the line since now this stuff is even more useful. I'm not sure if I have enough in me to finish this up tonight, but at least tomorrow, then I can get back to the outstanding things.

This was kind of way too much for so close to a release, but it needed to be done. Of course hopefully I don't know find some other way in which it's completely screwed up. But I think not.

I've got everything compiling now, and a quick and dirty test indicates it's basically working. So probably not too much to do tomorrow to get it done. Glad that's over.

And some testing and fixing, and a slight adjustment. But it's looking pretty good now, finally. I'll bang on it some more tomorrow.

Charmed Quark Systems, Ltd. - Support Forums and Community

Dean Roddey

kfly

kfly

Dean Roddey

Dean Roddey

kfly

Dean Roddey

Dean Roddey

Dean Roddey

Dean Roddey