andrewm

Yeah thanks. I thought I'd try here first to avoid burdening Support, but I've now gone ahead and contacted them as you suggested. For those interested in this area, Michel kindly responded that I should use "Emporia Vue, for which there's a node server" The product guide for Emporia is on their website here. I suspect that the node server will have to go out to Emporia to get its data rather than communicate directly with the meter as at present. My preference would always be to do as much locally as possible, rather than be dependent on external services, but it's not a deal breaker.

I've got the 21050 Smart Meter Module installed in my ISY 994 to obtain usage info from my electricity meter. I couldn't find much mention of the equivalent functionality wrt ISY on Polisy. The only smart meter Node Server I saw obtains its data from ISY I did receive a recent email from UDI regarding the Zmatter module which says "Easy migration from 994 500 series" though I don't see the "500 series" label in the UDI store to determine if this is relevant to me. But that email also implied the Zigbee radio isn't yet activated So is there an upgrade path for ISY on Polisy that will still allow continued retrieval of data from my smart meter? If so where do I find the information on doing that? If not is there another approach that people are using? Thanks - Andrew

I just noticed an issue with the Climacell data being used in my irrigation system. The rainfall variable (GV6) is no longer being created in the forecast node. The variable is still documented in the Poly's Readme file, but it looks like it was removed in the change to use the Climacell v4 API, though I didn't think I was using that; I certainly didn't have a v4 API key until just now, though I have now just upgraded the poly and created a v4 API key. While creating my new API key I took a look at the v4 docs and do see that the v3 API was supposed to have been turned off on June 1st, which could explain why I'm just noticing issues now. Additionally, I don't see the forecast rainfall as a specific attribute, (though the API does have accumulated snow and icefall) which would seem a retrograde step if correct. But I'm not familiar with their API - maybe the precipitation accumulation is supposed to be calculated by aggregating the timeline values? If this daily forecast datapoint isn't available in Climacell it leaves me needing to switch to a new weather provider. I do have a Tempest and did see references above to a Weatherflow forecast module. Is that something that's going to be available within a few months? In which case I'll wait for it, otherwise I'll just find something else. Thanks.

@bpwwer I just confirmed my Climacell website credentials only work with the "Weather API" login. Their dashboard still shows I'm making zero API calls, but the forecast in the ISY Admin Console at least shows the correct weekdays now, so I think the Poly is talking to something, though I didn't restart it. I don't need this to be working until I start irrigating in a few months, so I think I'll wait for clarity - presumably sometime after the supposed February switchover. Climacell are really making things confusing! Thanks

Hi Bob, I was just doing some "holiday maintenance" and thought I'd take care of this change while it's in front of me and I remember it! But going into my free Climacell account I don't see any reference to an API version. Their dashboard is very simple and I just see a key and an indication my account will auto-renew when it expires in June. So I'm somewhat confused as to what if anything I'm supposed to do about this change. Unrelated to the above, while in the Climacell dashboard I saw their widget that graphs the number of API calls being made by my account. That number has dropped from around 900 daily until December 10th, when it dropped precipitously to 256 calls on Dec 11th and since December 12th it's been recording zero per day. The ISY Admin Console shows the nodeserver as online, though the current-day forecast is for Saturday, but today is Sunday, suggesting I do indeed have a problem A quick review of the Climacell log doesn't have anything that screams out at me, though I wouldn't really know what to look for. It'd be nice if somewhere a field indicated when contact was last successfully made with the Climacell servers. Before restarting the nodeserver I thought I'd check in with you in case you wanted me to do something first. Thanks - Andrew

Just upgraded from 5.0.16c to 5.3.0 and I'm seeing an artifact / error on some of my switches related to the Beep: I don't recall it being there before, but I can't be sure as I don't live in this UI! This particular switch is a 2476D. I didn't check all my devices but I'm seeing it on other 2476D's but not the 2477D. Also some Lamplincs but not others. I assume it's older devices which don't support the Beep functionality; in which case a better indication would be to disable the widgets rather than display gobbledygook.

Thanks for the response - I'm glad you're untangling this for us! Seems like we should leave it to the nodeserver to work out what the best data is (raw vs corrected / local vs server). So I should leave the station publicly available, at least until such potential future time as the nodeserver implements authentication against the weatherflow server. If the nodeserver is going to the server, does that mean it gets access to more generic forecast data, such as rainfall forecasts? Just wondering if I'll be able to retire the other weather-related nodeservers? - Andrew

Well, setting the hub to be publicly visible fixed things. So how is the Weatherflow nodeserver getting the data? Is it getting it from the hub, from the Weatherflow server, or some combination?

I have a 2-month old Polisy successfully running the Climacell and Weatherbit nodeservers. My brand new Weatherflow Tempest just arrived to add into the mix, but I can't get the WeatherFlowPoly to work. I get 9 nodes added but the values are mainly zeros, apart from the ""Hub seconds since seen", which is 1594972239! This is the log I'm getting after restarting the nodeserver: MainThread polyinterface INFO polyinterface:init_interface: Received Config from STDIN. MainThread polyinterface INFO __init__:<module>: UDI Polyglot v2 Interface 2.0.41 Starting... MainThread polyinterface DEBUG polyinterface:get_network_interface: gws: {'default': {2: ('10.11.11.254', 'igb0')}, 2: [('10.11.11.254', 'igb0', True)]} MainThread polyinterface DEBUG polyinterface:get_network_interface: gw: default=('10.11.11.254', 'igb0') MainThread polyinterface DEBUG polyinterface:get_network_interface: ifad: igb0=[{'addr': '10.11.11.205', 'netmask': '255.255.255.0', 'broadcast': '10.11.11.255'}] MainThread polyinterface INFO polyinterface:__init__: Connect: Network Interface: {'addr': '10.11.11.205', 'netmask': '255.255.255.0', 'broadcast': '10.11.11.255'} Interface polyinterface INFO polyinterface:_startMqtt: Connecting to MQTT... localhost:1883 MQTT polyinterface INFO polyinterface:_connect: MQTT Connected with result code 0 (Success) MQTT polyinterface INFO polyinterface:_connect: MQTT Subscribing to topic: udi/polyglot/ns/5 - MID: 1 Result: 0 MQTT polyinterface INFO polyinterface:_connect: MQTT Subscribing to topic: udi/polyglot/connections/polyglot - MID: 2 Result: 0 MQTT polyinterface INFO polyinterface:_connect: Sent Connected message to Polyglot MQTT polyinterface INFO polyinterface:_subscribe: MQTT Subscribed Succesfully for Message ID: 1 - QoS: (0,) MQTT polyinterface INFO polyinterface:_subscribe: MQTT Subscribed Succesfully for Message ID: 2 - QoS: (0,) NodeServer polyinterface INFO weatherflow:start: Starting WeatherFlow Node Server MQTT polyinterface DEBUG weatherflow:process_config: -- configuration is valid NodeServer polyinterface ERROR node_funcs:get_saved_log_level: Found saved log level 30 NodeServer polyinterface ERROR node_funcs:save_log_level: saving log level to customdata NodeServer polyinterface INFO polyinterface:saveCustomData: Sending customData to Polyglot. NodeServer polyinterface INFO node_funcs:set_logging_level: set_logging_level: Setting log level to 30 NodeServer polyinterface ERROR weatherflow:query_wf: Bad: 'stations' NodeServer py.warnings WARNING warnings:_showwarnmsg: /var/polyglot/nodeservers/WeatherFlowPoly/nodes/weatherflow.py:373: ResourceWarning: unclosed <socket.socket fd=7, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=6, laddr=('10.11.11.205', 15696), raddr=('107.22.116.161', 80)> NodeServer polyinterface ERROR hub:__init__: No sensor devices found (Sky, Air, Tempest) "Bad 'stations'" seems to be the problem, but I'm using what I believe is the required station ID from the hub's status screen. I've not entered any other config data in the NodeServer. I did completely reinstall the Nodeserver just to be sure. Note that I've not set the Weatherflow Hub to be publicly available, believing that the NodeServer is supposed to talk directly to the hub over UDP.. But maybe I'm mistaken, because the above log does show an attempted connection to an Amazon AWS IP. I do prefer not to have things publicly visible, at least until they're bedded in. Can someone clarify this for me? Thanks - Andrew

Thanks for the reply. I was hoping to have some low-voltage I/O capability. Do you or anyone else know if it'll be possible to use plugin USB boards for that, or will we have to have separate external devices, such as Raspberry Pi?

The Polisy product page is very light on hardware specs, and I can't find them in the forums. It does state "3 x 1 GB Ethernet ports", which is a start but then adds "extensive I/O features" which is very vague! So my specific questions would be: - How many USB ports? - Does it have user-accessible GPIO capability? - Does it have relay outputs? If so, what are the electrical specs? - Does it have a cooling fan? Thanks in advance - Andrew

I had a very similar issue to others here which stumped me for a while. I have multiple scenes in the kitchen, one of which is "All kitchen lights". At some point that scene stopped working via Google Home - the lights would turn on then immediately off, or some random combination thereof. But it worked fine via Amazon Echo. I guess Google is trying to be clever by interpreting the world "all" and then controlling all the related "devices" it knows about, which given they are scenes has weird results. The work round is to use synonyms for "all" (entire, complete, everything) but that's effectively whack-a-mole, because Google will eventually work out the synonyms and I'll be back at square one. Google should instead try for a more exact / literal word match against the spoken before trying to add interpretations based on word meanings. So much for Artificial intelligence!

Ha. Maybe AI can fix the damn AllOn problem!

I have the same problem as the OP. It seems like Google decides if any words match and then turns on all the matching devices. I think it does indicate in its confirmation whether it has a unique match (eg "Turning on normal family room lights") vs an approximate match (eg "Turning on 3 lights") - the number in the latter indicating there are multiple matches. Unfortunately, though, there's no way to know which lights (ie devices / scenes / whatever) it's decided to turn on - it'd be nice if the Activity Detail included that, and it'd be nicer still if you could feed back to Google the fact it got it wrong!

I've recently upgraded my ISY 994i with the High Powered Zigbee Smart Grid (SEP1.1) Radio so as to connect to my PG&E smartmeter. I do have connectivity and am receiving meter usage info, but no pricing information. Looking around the forums I found a post that mentioned changing the firmware when the new radio was added. There were no instructions provided with my hardware upgrade, so I hadn't realized this was necessary. However now having changed to the ZS firmware, I'm not seeing any change in functionality - it's not working any better and I'm still not getting pricing information. Our PG&E plan is based on net metering with Time-of-use (TOU). Should I be getting that pricing info from the meter? If so, how do I work out where the problem is? - Andrew