Charmed Quark Systems, Ltd. - Support Forums and Community

(01-26-2018, 02:42 PM)potts.mike Wrote: [ -> ]So IÔÇÖm doing this with smarthings now and IÔÇÖll be able to do in CQC.

Yes, you should be able to do that.

I got further along today, though still not back up to where I was before. Lots of if's, and's, but's and gotchas. But I got pretty close. There's just no way to do a non-complex, non-brittle Z-Wave driver, but this scheme is less so than before. It's just that it's very stateful now, and how the state changes depends on various things at various points. That's something that's easy to mess up. It's not really possible to centralize that decision to one place where it can be carefully controlled. It's pretty spread out.

I got almost there today. One complication that I ran into is the whole thing of not knowing what fields to create until we get info on the unit, but we can't just let fields show up willy nilly. That would require re-registration of the fields, which (because of how field management works) will cause IVs to blinky and such as they re-sync.

So I changed it such that, on startup or after replication, any units that already have device type info set on them, I get the basic node info (which just comes from the Z-Stick.) If that hasn't changed, I assume the device type info is still good and I let those nodes create fields. The others are then just left to gather data in the background.

If they can get manufacturer ids and if we have a match for that type of device, then it will go into a WaitApproval state, where it's not allowed to go live, but we do have the info for it. So when you bring up the client interface, that'll be set up correctly already. You just need to set any options and save, and those will then become ones that get fields created for them. It's probably best that way anyway, since you do generally need to set options.

The others, as I said, just collect what info they can. You can ask for that info and save it to an XML file that you can send to me, so that I can know what is involved in adding support for that type of device. And the client side interface will be able to display it also (I haven't even started on the client part of it yet.)

And, this also deals with battery powered ones. If they already have device info, they are ready and their fields will be created, though they won't be filled in until the device wakes up. If we don't have device info, and we get a wake-up, we'll send a query for manufacturer ids. If it supports them, we'll get that report. If it matches something we know we can set up that unit and put it into WaitApproval state as well. This is a far more sane way to deal with wakeup type devices.

If a unit's found info doesn't correspond to what it's configured as, it'll be put into a failed state and you'll have to use the client interface to reset it. It won't reset automatically because that would be dangerous. Some commands your logic sends it, based on what it was, might still work on what it is, and that could be bad.

Anyhoo, I'm currently going through the info gathering steps and working out glitches there, but mostly it's working.

And I have to give more props to this guy. One of the most ridiculous bassists out there, doing stuff so different, both in content and technique.

https://www.youtube.com/watch?v=HBxEF-nQK04

OK, actual progress is being made. The driver is correctly setting up those units it has been able to get specific device info on. For non-listeners a wakeup gives it a change to get that info and it'll pick those up if a wake-up happens before you manually set it.

I changed the code that gets the unit info dump file, so that it just uses what has been found already, it doesn't have to proactively do a long query process. It works now via the QueryTextVal backdoor command so the client side driver will be able to let you query it, display it to you, and give you a chance to save it to a file. It'll contain whatever information the driver has been able to get.

For any units that did not already have specific device info when the driver comes up, if it gets that info, it goes into a state that indicates it has gotten the required info and is ready to use. The driver will periodically check for such and, if found, it will re-register its fields to get them online. Or, if you make any changes via the client interface and save, those types will then go live, so you can force it immediately if you want. If the driver reloads at any point it would also end up bringing those types online as well.

I haven't implemented that periodic accumulation of newly recognized units yet, but I'm going to. As mentioned above, we don't the driver doing a bunch of field re-registrations since it will cause blinkies in the IVs. But, to check every five minutes is fine. It will only happen the first time a wake up is seen from a unit after it is added to the network and a new replication is done (so that our driver now sees it.) So it's not like it will happen on every wake up or after every restart of the driver.

So that's regular units, battery powered units, and secure/beaming units that have been incorporated. That's basically it in terms of the major families of Z-Wave units. Everything will fall into one of those.

So I'll do the periodic check for new units, and then move on to getting initial values, and start adding in some code to the base unit class to handle common functions like battery level, so that every derivative doesn't have to deal with that.

I have to say, my msg I/O stuff seems really solid. Whooda thunk it back months ago? I'm never changing it again.

(01-20-2018, 04:14 PM)IVB Wrote: [ -> ]Align middle isn't working. Trying to align a command button and a field checkbox, first the field checkbox disappears, then when I try and save I get "could not create the rectangular region (numbers) object. The parameter is incorrect.

I had just resized the field checkbox, it's smaller than the image inside it (intentionally).

I've fixed this for 5.2.11. That's the only code change from 5.2.10 so far. So I'm going to do some doc updates and probably make a new 5.2.11 the official version tomorrow after some testing.

Were you able by any chance to modify the webriva to pass on the pinch zooming to the browser on android?

Without it any interface is ackward...

I haven't looked at it yet. I want to get a new official drop out first before I start making any more changes that might take a while to validate.

So, taking a quick look at it, just to see if it's obvious... I think that I will have to implement zoom myself. Because we have to handle gestures, and because there's no way to know up front whether the start of a gesture is going to result in a zoom operation, there's no way to let those propagate through selectively.

Since, in most phone/tablet scenarios the canvas fills the whole screen, you can't do the pinch in the surrounding background area. That works since I only handle gestures for the canvas itself. But, once it's full screen you can't get to any background to do it.

So, anyhoo, implementing pinch zooming isn't something to whip out quickly just before putting out a new followup release.

What's weird is that I could just use mouse input only. I.e. never get involved in gestures at all. But, when you are on a multi-touch screen, at least in Chrome, drag gestures aren't translated to mouse events. click gestures are, but not drags, so you can do any swipe gestures on the template unless I handle gesture. Edge correctly reports them as mouse input, but not Chrome. I put back the gesture handler and had it just explicitly indicate I wanted to pass on all gestures, but that didn't help either.

So, ultimately, I need to handle gestures (and in this case I ask that they NOT propagate, so that they don't turn into mouse events which I'd see as well.) So that means I'll need to implement pinching.

well, nothing is simple isn't?

so I told you about my efforts on reproducing an android app as webriva interface. It is surprisingly easy to work with existing graphics that is made for that
where I am struggling is to reproduce some of the menus that are typical in an android interface. This would be so much easier in html and some javascript. Any strategies you recommend?

Since Webriva is a web server, could we layer on top of the canvas which does the CQC Riva magic some good ol' html+script? to have for example a toolbar or menu?