Jump to content

FerventGeek

Members
  • Posts

    55
  • Joined

  • Last visited

About FerventGeek

  • Birthday October 23

Profile Information

  • Location
    Austin, TX
  • Occupation
    AIOps Architect

Recent Profile Visitors

1335 profile views

FerventGeek's Achievements

Experienced

Experienced (4/6)

9

Reputation

  1. Thanks Geddy! 994i Pro - Thanks, I updated the post USB PLM - I bought it as soon as Instron had them back in the store. Seems like the right route to eliminate the need for the blue adapter cable (with another inline processor), and it's 10 years newer. Since that is the most critical interface, I'm trying to make it as reliable as possible. So in this regard the ISY994 to eisy is a one way trip and there's no way to know if going from the 994 on it's serial PLM to the eisy on a new PLM will work? Portal - Yes I'm letting go og MobiLink. And I already interface all my external integrations via a custom AWS Lambda function, so that will be a single point for any modifications to the XML API. (The lambda is an XML<->JSON gateway with additional features and fine-grain RBAC auth.) Polyglot - I'm running both 2 & 3 on the Polisy as there are a couple of legacy PG2 plugins that aren't available in the store. I'm assuming that the eisy can run both Polyglot's like the Polisy. If not, it's a dealbreaker for now, as I don't have time to hack PG3 versions of both. Thanks again for your assistance. It's a lot of moving parts, each of which has "should" work's.
  2. I’m going to bite the bullet and finally combine all of my accumulated UD gear into a single eisy (assuming they come back in stock). I’d love for you experts to weigh in on my upgrade plan. Here’s my current, reliable if old, setup: ISY994i Pro (Instron and Z-Wave devices) Polisy with PG 2 & 3 Plugins and lots of integrations ZMatter card (never installed) Instron serial PLM MobiLinc portal for remote APIs I'm planning to migrate all that to eisy using the following path. Please let me know if you think this will not end well. On the existing isy994, migrate from the Instron serial to a new USB-based PLM. Let it run for a couple of days to ensure all is well since it’s the house's core. Put my never-installed ZMatter card into a ZMatter USB Enclosure from the UD store. Plug the now ZMatter dongle into the eisy Do the backup migration from the ISY to the eisy Migrate remote management to the ISY Portal Troubleshoot Z-Wave Do the backup migration from the Polisy to the eisy Profit? Thanks for your assistance!
  3. Thanks. It's hard to know where to post platform interface questions. Because the ISY source is closed, it makes sense that core dev support is also closed- i.e. no public forum. However, the REST interface is documented, minus it's primary interface schema. Mostly I try to ask the community first for self-service, before bugging the Universal Devices team. I'll ask them directly.
  4. Is there a magic link to an XSD or other doc for the ISY XML schema? I'm finally converting my handicraft XML to JSON converter to a Python library, and am wondering if the official ISY XML schema is available somewhere. I've been lucky to find several great libraries to draw from, but each has it's limits. Generally, they only convert what they need to based on white-box understanding of a subset of XML responses. This makes sense- why reverse engineer every possible message and device type if you don't have to? However, I'd like to clean up my transformer to look as close to an "official ISY" JSON response format as possible, then do the app specific transforms on that. There are great general XML->JSON libraries available, but end up including unnecessary or duplicated meta that a schema-aware transformer would omit. Thanks!
  5. I have the serial Instron PLM, not the USB version. USB would be a non-event.
  6. Google + Thingaverse are magic. This just showed up today, fits perfectly on my Polisy. Slight delay of game for the Zmatter driver, but getting really excited about the migration from my ISY994i. Chipset troubleshoot yea verily, firmware team! My wall is ready. https://www.thingiverse.com/thing:5221086
      • 1
      • Like
  7. Thanks Michel. I did, I’ve got it sorted
  8. I apologize if I'm taking this topic too seriously. I've been very fortunate to help build and manage large communities, so the sprit of what we're doing here matters to me. Both for the community and UD's long-term business goals. Do believe that UD's years of support help motivate to our ongoing new purchases? Do you believe that post-sales support is important to draw-in new users? As ISY is closed-source without extensibility for portal integration, is there some other forum to ask questions related to UDs 1st-party portal integration framework? As previously mentioned, I've already accepted that UD EOLs features as it sees fit and will solve this regression myself. The question is- is this an open forum to ask questions related to our use of UDs products? I'm not sure that your opinion that UD should be like Apple and do whatever it wants without comment, is good. For the community or UD. The point of the platform- our platform- is that it is not like Apple. It's not a walled-garden to take or leave. Maybe I'm just old, but in my mind it's always been open, collaborative, encouraged 3rd-party integration, and as a result stood the test of time. I'm just a dude trying to save effort and UD has no obligation to do anything I might request. But I'd like to think UD intends to be open to conversation. And that's not Apple-like at all.
  9. @asbril, where am I insisting they continue support?
  10. So if you buy a GM vehicle, GM can stop making spare parts for past-model vehicles, and you won't ask if there's another option? UD- like GM- had a significant financial incentive in the past. And if you buy a product like a car, you do so based on many factors, some expectation for ongoing support being one of those. As you'll notice above, I already said I'd adapt, so urging me to migrate is moot. What I've asked is a normal consumer product question: will my previous investments in a platform carry forward? I'm doing what software customers do in communities- share my user persona and user stories with the product team. They should take that under advisement, as the most valuable source of product feedback and features is not existing super-users. Existing customers generally don't have the financial benefit to business that new to brand customers do. Unless.. you can cross sell or upsell new products and services into existing users. Cost of acquisition CTA is low, and it's easier to retarget or remarket new adopter content to your existing base. So in that example, UD has a lot of financial incentive to engage with me. Sale-after-service for me has been far more than my initial ISY purchase. That means the majority of UD's revenue from me hasn't been for the ISY device platform. It's in follow-on up/cross sales. In the GM example I'm on my 2nd or 3rd car of the make. It's fair for me to hope that there's a solution that does not require additional work on my end. It's fair for me to ask for it, and fair for UD to backlot it. But to say I'm not a paying customer, that UI and I don't have an ongoing financial relationship which typically includes support is incorrect. Worse, saying UD should not care about existing customers once the a purchase is made, does them tremendous disservice in 2022.
  11. No. I'm here to understand. I also accept that like Linux and Apple forums, members in any community- no matter how otherwise excellent- can become so attached that honest questions seem like attacks. And if you spend time in those more toxic forums, you can appreciate how important it is to welcome newcomers. Especially for complex pro-sumer gear like UD. That begins by assuming that even stupid questions are exactly what they seem to be. It assumes new members aren't on a mission to badger an old guard. It assumes a poster's frustration is driven by a shared passion for the community and a desire to find answers. It assumes new members are eager to deepen connection with experts. That's how great communities are built. I urge you to review my other posts in these forums and assess my intent. You'll find nothing from me where I'm sarcastic toward other members, much less basing the first sentences in posts that way.
  12. Right? Putting my software product manager hat on, I think the logic goes something like this: The ISY can't support two portals. Mobilinc was THE portal ISY "portals" was originally that UD extension working with Wes Later, UD Portal would use the internal ISY C library API first created for Mobilinc The goal would have been near-zero changes for the portal hooks in ISY The only way now to support both portals would be a decent chunk of new ISY code UD would need to abstract portals into a class, and manage messaging for a list of them That code would need full regression testing and change the UD support process All that adds to costs and risk and UD PM didn't see the value The future of UD is an all-in one that combines the ISY heart with Polyglot node adapters to deal with the never-ending parade of proprietary home automation protocols UD would love a modern re-write of ISY, including a modern JS UI to replace the Java console, more advanced logic, and abstract node definitions within ISY. However that's waaaay out of scope. Therefore, UD needs to support the device with a SaaS interface based on what they have on the truck. And Portal needs to be stupid-simple to configure and ready to go UD PM had to make a choice There aren't resources to extend the internal ISY portals interface They have to have OOTB portal working to drive adoption (accelerate UD onboarding) So it's UD Portal, sorry Mobilinc I've stayed with Mobilinc for two reasons The main one- I don't want to have to reimplement integration code and re-deploy several AWS and Azure interface services. Also, regression testing for human-factors driven long-cycle async code takes weeks to catch edge cases in API quirks. Mobiinc has been rock-solid. Looking at the US Portal forum, that's perhaps not the case just yet. So, I'll adapt.
  13. Thanks. I already built something like that- golang subscriber pushing to AWS SNS. Still hoping it will eventually be built into a portal. The old SOAP wrappers have all the magic.
  14. Thanks. Yes, everything has been centralized on my ISY for a decade. I've watched protocols come and go. That's why losing connectivity (without re-implementing custom integrations via Mobilinc) is painful. I'll effectually lose the center of my automated world. I'll stay on the ISY99 until I have a solution. Maybe an intermediate AWS Lambda function that's UD Portal on the backend, and Mobilionc REST on the frontend. They're both wrapped local ISY REST.
  15. Ah. I just followed the emails. "Hey we have Polisy now for node integration" - bought one. "Hey we have an updated Z-wave+ module for the ISY" - bought one. "Hey we have a new card that lets you migrate ISY to your Polsy and get Matter and Zigbee" + pre-ordered on announcement day. To find out this late after all the announcements, documentation review, and purchases that my primary interface to my home automation may have been been cut.. is more than a bit of a surprise. And disappointing. This isn't a rant- I'm invested pretty far in.
×
×
  • Create New...