mwester

As a general rule, NO programs should run as root -- but specifically as they relate to node servers, you can't run as root on the Polisy, which might be an issue if the code in question is to run there (no reason that weewx couldn't run on the Polisy -- that's certainly a tool I'd like to move off the RPI 'cause I feel a lot better about a proper SSD compared to the reliability of an SD card). Just an FYI for node server and Polisy developers.

Check if your UI is the same version as the firmware in the ISY.

Kinda sorta mostly. There's no way to configure or set up the tags or the tag manager locally... so you need their cloud server for that. However, in that setup you can give the tag manager a local URL to a system of your choosing, and once that's done the tag manager device will operate locally (even if the connection to its cloud server is missing). So, the node servers (and other things) that one uses with these devices are local, but the system as a whole is dependent on a cloud-based service. I use a few of these for non-critical things -- I despise cloud-based services (look at what's happened with the Nest, as well as with a few of the providers that have ceased operation) but I rationalized these things based on their low price and the fact that they mostly work locally. If the provider starts charging for their service, or go under, well, the tags are pretty much disposable at that price point.

Yes, it has bluetooth -- like all modern computer wifi/bluetooth combos, it shares the antennae with the wifi. One could reasonably expect that the antenna issue might affect the bluetooth, but in as much as the bluetooth is not yet enabled on the Polisy, it doesn't matter at this point. One the driver is sorted out and all that, there should be an update to the Polisy that would enable the bluetooth functionality - no idea when that might be, though.

Yeah I get that - just trying to provide readers of the thread with something somewhat familiar. Sorry to bother you!

I moved my hass system from the rpi to one of my kid's retired laptops - not because it was slow, but I had an SD-card failure on another rpi that convinced me that platform's I/O isn't ready for something that read/writes to disk a lot and needs to run 24/7. However, I just successfully got a core (base) hass system up and running in a "jail" (FreeBSD's answer to docker) on the Polisy... that probably won't scale as large as an i5, that's true - but for small environments, that has a lot of potential.

Kinda proves my point -- the concept of "Let's duplicate EVERYTHING from the ISY into HASS!" is flawed right out of the gate. We'd never to that in any other system architecture, so why do it for the ISY? (I think the answer to that question might perhaps be in the way the ISY is designed -- you either grab info bit-by-painful-bit, or you subscribe to the "fire-hose" that sends every action about everything in XML down the wire. Of course the receiving side could filter that - but filtering is hard, and doing it on the RX side is not the ideal place for that either...) If you have 1000 nodes on the ISY, it makes no sense to mirror that into any other system (and it won't matter if it's x64, arm, or an IBM mainframe!)

Just a guess - but it sounds like maybe you didn't update your UI to match the new firmware release? That's the first thing I'd check when you seem to have so many things "gone missing".

Never looked at mine, since I don't use the wifi (folded up the antennas, and ignored them...) - but same here. I believe the correct terminology for those connectors is SMA and RP-SMA (for Reverse Polarity SMA). And no, it's not normal to attempt to connect an SMA with an RP-SMA - as you note, the center pin (the antenna) will never connect, so it's pointless. The manufacturer's site doesn't state conclusively if mixing the two was intentional, but I'd have to assume that it wasn't intended - probably the one pigtail from the card to the chassis is wrong. It might be really convenient to have one of each -- the SMA is the "standard" connector, but a lot of routers early on used the RP-SMA (Linksys for example). So I have a few higher-gain antennas with the RP-SMA connector that should fit very nicely - and add a bit of range to the wifi. But for those who don't want that, perhaps swapping one of the antennas out, or using an adapter is the solution. A glance at Amazon shows dozens of adapters all about $5/pair -- and likewise, numerous RP-SMA wifi antennas, at all sorts of prices (not all of which are legal in the US per FCC rules, but that doesn't seem to stop the sellers! )

I'm betting you're using a Mac. Your browser is automagically expanding the "zip" file and showing you the contents. You'll want to download the zip file as a single file. Not being an Apple-person, I don't know how you do that - just that many on this forum have encountered this same problem. So if you need more info, I'd suggest a deeper search for firmware issues with Macs might find exactly the solution you need.

No big deal -- a lot of the early units got bounced around worse than that in shipping (mine arrived with BOTH the wifi and the SSD cards loose!). Just pop them back in place. The hardware designer chose to use spring clips rather than screws to hold the boards down, which is great for hobbyists, but as you've noticed, not so good for shipping.

Might I suggest that perhaps simpler is better -- not only "best practices" better, but also better in the sense of one's sanity? Feel free to disagree... I've run hass and an ISY for a long time -- independently. Reading the experiences with the integration on this forum convinced me not to attempt to integrate the two. However, after an unfortunate event with one of the alpha firmwares on the ISY, I moved some of my z-wave to the hass system, and that force my hand. So, given the general poor reviews of the formal ISY integration in hass, and the commentary here about pyISY, I chose to integrate using variables and network resources. The hass system makes REST calls to the ISY to set various state variables to signal the handful of important things that it needs to tell the ISY about. The ISY uses network resources to make REST calls to the hass system to tell it about important things that the ISY needs it to know (e.g. the z-wave siren is on the hass system - when the sump pump runs a long cycle and alarms, the ISY lights up a red KPL button, sends a text message, and the signals to hass that it should sound the siren for 30 seconds). I have a reasonably large setup -- and only a very small handful of "messages" that need to be sent between the two systems. Network resources and state variables are quite sufficient to do the job. And as for best practices, the idea of exposing only what is necessary is a key theme in designing quality systems, so it seems to me that the apparent "gracefulness" of having everything in the ISY mirrored in hass is actually not a good engineering design - it's asking for reliability issues right off the get-go. I certainly accept that one has to plan and isolate the two approaches -- you can't have the switches in a room on the ISY while the lights are all on hass. But I'd argue that if you did that, any problems you have with integrating the two are not due to reliability issues with either the ISY, hass, or pyISY -- they're primarily due to a not-so-good device layout! It's unreasonable to think that either the ISY or hass would be designed so that you could "glue" another completely different controller onto the side, and expect the franken-troller you just created to be as reliable and manageable as either one of the two alone. Just some thoughts...

vi is to real text editors as a bootloader is to operating systems. That said, I'd agree that everyone should know at least the bare basics of VI.

Alas, no -- the ISY does not at present support the use of anything other than the primary admin account.

Sigh. Ain't that the truth -- and not just for hobby-related things, I have this problem at work too. I blame it partly on things like twitter -- we've an entire generation entering the work force that can't read anything longer than 144 characters. Anything more, and they want a video (!), or preferably, they want me to do it for them. The following acronym makes me "see red" -- anyone using this in an email or IRC chat even at work will find the conversation suddenly cut short due to "network issues": TL;DR Just typing that makes smoke come out of my ears... (I now return you to your regularly scheduled forum...)

I'm with simplextech on this one. I've seen too many cases of what I term "GUI-First" development, wherein the phone or tablet is the primary focus, and as a result, the actual functionality of the solution ends up suffering, or in a couple of cases, the core functionality atrophies into the smaller set of "whizzy" and "cool" things that one can do from the limited tiny GUI display and the user-level-assumptions that go along with that. I'll toss out an extreme idea here. I'd like to see the ISY/Polisy solution architected rather differently: a) Core functionality supported by a CLI that drives a REST API to do the work on the Polisy and the ISY. This functionality would include: - adding/deleting/managing devices and scenes - diagnostics and health - uploading "compiled" programs and network resources a) which implies that programs would have a text-based "source code" that would be "compiled" for one's ISY/Polisy This would address a large need for being able to manage and version control large implementations - particularly good for installers, for example. b) Core UI management functionality supported by a browser-based GUI that does a useful subset of the day-to-day activities involved in managing the Polisy/ISY. - includes uploading programs and network resources, but not authoring same c) An "authoring" UI built on anything UDI likes, that would allow GUI-based program and network resource creation, much like the current Java-based IDE does. d) A mobile solution that is a stripped down version of item b above, unless perhaps item b can be coded to work on both -- although I have to say that I find phone GUIs ported to a full-size web browser to be hard to use, annoying, and make me want to run to the command line instead... but to each their own. e) A authorization-limited version of the REST API should be exposed for general user use, along with a "web toolkit" (examples and a library) that would facilitate technical users creating tablet-based or phone-based or even PC-based apps to do user-level actions to control the automation. This would exclude management, and development activities, and thus should be a very small set of functions. The fact that it has a separate user (or better yet, auth key) would ensure that even if someone reversed the app, that person couldn't gain access to the admin level actions for the Polisy/ISY. I'm dreaming, of course... but if there's one thing I'd like to NOT see, it would be having UDI try to port the entire ISY experience to a phone. Please, please, don't go there.

Normal.

Excellent use-case that illustrates the challenges of programming something that humans would find so easy to do! A human being given a thermometer and the task to turn the fan on and off as you describe would have no troubles with understanding what to do, and handling the exceptions (e.g. the water warms up to 30, and never gets any hotter, nor colder -- eventually the human would turn off the fan and go figure out what happened... but alas, you'll have to sort out that (and other) failure cases on your own with the IS). So, first thing to note is that as you've already described, the obvious choice (a range of temps to trigger the on/off) isn't going to work. So, start by re-thinking that a bit. What *really* triggers the on and the off, if it's not the absolute temperature? I'd investigate the idea that it's the *direction* of the change in temperature as it crosses those select absolute temperatures that might be useful: if the temp now is greater than 25, and 30 seconds ago it was less than 25, then we're on the way up, and the fan should be turned on... opposite for turning off. Next, I'd strongly suggest adding some timeouts just in case. How long is long enough for the fan? And perhaps an alarm -- if you have a spare button on a KPL, one might illuminate that if the fan has been running too long. As for implementation, there is some dissension on the forum... some might favor writing this in as few programs as possible, maybe using folder conditions to do so. I find that becomes inscrutable and difficult to debug, so I would simply create a folder for "Bathroom Auto Fan" or something like that, and add a bunch of programs to that. I'm sure that you'll have plenty of folks offering detailed programs, so I'll refrain from doing so... mine are a bit complex, since they include auto-off timers, alarm states, and the like (I use this technique for the roof-deicing cables, door entry/exit alarms, bird-bath heater control, sump pump monitor, etc.)

Look up the parameters that this device supports (should be available from Zooz, I'd expect). Most vendors support a means to send a parameter to the device to change the nature and frequency of reporting -- some are easier than others, but I've had no problems adjusting my reports to the 5 minute range (I really don't need updates every 30 seconds - the temp and humidity don't change that fast!)

Some tests with a collection of USB sticks shows that, in general, the current FreeBSD kernel on the Polisy cannot handle USB 2 storage devices plugged into the front panel USB ports. It works just fine with USB 3 storage devices. I've not tested with actual disk drives - just memory sticks. And I've not yet tested the internal USB 2 ports (need to dig up my motherboard cables for that connector -- why is that when you don't need things like that, you're tripping over them, but when you need them, they're nowhere to be found???). I also tried the USB 2 sticks with a USB 2 hub connected to the ports (a solution that I've used for flakey USB-2 devices on laptop USB-3 ports in the past) - no difference. So it suggest the problem is the USB 3 chipset or an OS driver bug... Here's the kernel messages from one such device, for those interested: ugen0.2: <USB Flash Disk> at usbus0 umass0 on uhub0 umass0: <USB Flash Disk, class 0/0, rev 2.00/2.00, addr 1> on usbus0 umass0: SCSI over Bulk-Only; quirks = 0xc100 umass0:2:0: Attached to scbus2 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 2 more tries remain (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 1 more tries remain (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 0 more tries remain (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted ugen0.2: <USB Flash Disk> at usbus0 (disconnected) umass0: at uhub0, port 4, addr 1 (disconnected) umass0: detached For comparison, here's a USB 3 device that works: ugen0.2: <Kingston DataTraveler 3.0> at usbus0 umass0 on uhub0 umass0: <Kingston DataTraveler 3.0, class 0/0, rev 3.00/0.01, addr 1> on usbus0 umass0: SCSI over Bulk-Only; quirks = 0xc100 umass0:2:0: Attached to scbus2 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: <Kingston DataTraveler 3.0 > Removable Direct Access SPC-4 SCSI device da0: Serial Number 002618887F9BF050584230A0 da0: 400.000MB/s transfers da0: 7377MB (15109516 512 byte sectors) da0: quirks=0x2<NO_6_BYTE>

Yep - has the "mount_smbfs" command but missing the kernel module for smbfs... (Can we request this kernel module as well? - Thanks!)

Love to see the "unix2dos" package in the feeds -- provides both unix2dos and dos2unix utilities, which are rather nice for those moving files/content about. The kernel modules for the automounter would also be appreciated -- it would be nice to have the system automount a USB stick when one is plugged in. A long, long time ago, in a galaxy far, far away, on a network device that also offered no console for the average user, for our beta test units, we devised a means to extract logs and IP information from the device that involved a USB stick with a very specific directory layout. Applying that to the Polisy, one might envision a USB stick, empty except for a folder named "UDI" or "POLISY". Upon plugging that into the unit, and waiting for a prescribed period of time, one might unplug that USB device, and find a few files in that UDI or POLISY folder. An "ip.txt" file, for example, might have the IP address and networking information (to help a user find a Polisy that's been lost on the network). Perhaps a "logs" folder might contain a copy of the boot log (dmesg), the logs in /var/logs/*, and the polyglot logs. Going even further, one might envision that one could create a simple text file with network information that the Polisy could read from that USB device -- I'd imagine this would be used by a non-technical user who might be unable to get the Polisy configured with DHCP on their router, for example. For ease of use and security, it might make sense to have a simple page hosted on udi.com that would allow the user to enter their Polisy's serial number, the desired network information, and the site would create a downloadable "config.udi" file for the user to put in the correct place on the aforementioned USB stick. It wouldn't be hard to obfuscate the config.udi file, if desired, to make it less likely that someone other than the owner would play with the USB ports and change the networking config by accident (or maliciously)... although frankly, I think that being able to disable the config.udi feature via the web UI would be a better solution for those who don't need that feature. Now, this is a terrible hack, I'll be first to admit! But, when a device has no console, and the user is unable to talk to it on the network, you need to look around to find what that user might have that matches a port in the device, and it seems to me that the ubiquitous USB stick is probably the most likely thing lying about...

@Michel Kohanim - as an expert in breaking things (and generally pretty good with recovering them), I'll happily volunteer to be an early tester for that recovery mechanism. Let me know how I can help.

Yep, that pretty much matches mine as well. Most of the filesystems are pulled out of a single pool, and it looks like that pool is 5.2 GB in size, total. The partition table on the SSD suggests it's sized to the full 32GB. I've poked around with the zfs command, and it doesn't look like the various filesystems are using the multiple-copies approach, and it makes no sense to have RAID running on a single SSD, so there's clearly something else going on.

FYI, only the first slot supports msata cards -- the other two only have the PCI signals it would appear.