All Activity

I think you are describing Home Assistant well. There's some GUI driven scripting with YAML on the back end you can do, but it's designed for regular home owners, not just programmers. People make some pretty slick dashboards. Once I finish getting mine how I want I'll probably wall mount a tablet to display it in kiosk mode in a room or two. But to try to integrate LV with HA? Not for me.

This all sounds very awkward for a home automation GUI. Why would you compile software on the target? Surely all the devices are wifi with their own REST API so you only need an aggregating web server with pretty javascript front end. What am I missing?

I've got a HA Yellow dedicated device with a RPi CM 4. Some time back I bought two HP EliteDesk machines I bought on the cheap that I use for a plethora of "homelab" things, including my favorite self hosted app; Trilium. Both of these machines are running Ubuntu server with Docker/Portainer managing containers. The EliteDesks were cheaper than RPi 5's with all the necessary accoutrements to be self standing. So, something of a no brainer. cheers,

My HA install is running on bare metal computer, which is an 8th gen I3 embedded PC, 8GB of RAM 250GB SSD. Here is the install instructions. I wanted a bit more performance, and a company was throwing these computers away. Besides this can give me more head room to do other things if I ever want to. There's even an option to install HA on windows, but it mentions it in a VM specifically. Nevermind, this is explaining how to have it on Windows, which involves having a Linux VM.

Thanks Rolf, This sounds like a LOT more effort than I want to engage in. cheers,

They still have something akin to the Alliance Member program. Not sure if it is still called that. Used to work at one too, but am now in academia. As to running LabVIEW directly on a HA, that is not currently possible. Well it may be possible with some emulation if you get an x86_64 emulator running on your ARM HA hardware but that is: 1) a major project to get running, with lots of obstacles, many tricks and a huge chance that what worked yesterday suddenly fails for unexplainable reasons 2) a taxing solution on the poor ARM CPU in your typical HA box The current Hobbyist Toolkit is maybe the most promising solution at this point. It can deploy compiled VIs to a Raspberry Pi and run them headless on the Raspi. But as it is now it's a bit of a pitta. It requires its own chroot environment to provide an ARM environment that is compatible with the ARM CPU in the low cost NI RIO hardware. This is distinctively different from the ARM binary mode typically running on your Raspberry Pi or any other modern ARM hardware. It is 32-bit, and uses the so called softFPU mode where FPU commands are emulated on the ARM core itself, rather than using Neon or similar FPU hardware integrated in all modern ARM chips. And new Raspberry Pi OSes including what HA is using (when running on Raspi hardware) have all changed to 64-bit nowadays, which is with the current Hobbyist Toolkit still a bit of a hurdle but can be worked around if you know what you are doing. There is some talk from NI that they may maybe support a native Raspberry Pi version of this, where the LabVIEW program is deployed to the actual Raspi itself rather than into a chroot container on the Raspi. If that is ever going to see the light of the public, how and in what form is completely unclear. There are several challenges, some technical such as making sure the LabVIEW runtime properly can interact with the window manager on the Raspi (that should be fairly trivial as it is the pretty much the same as what LabVIEW for Linux needs) but also more economical/marketing: How to justify the effort and cost of developing and especially maintaining such a solution without any tangible income in the form of hardware sales? Making it an extra licensed feature is also not very feasible, people are usually not willing to pay 100ds of bucks for a software license for something to run on a 50 to 100 bucks hardware platform. And even with that, your development would still be on a Windows box, in the same way as you develop code for the NI RIO hardware, where you have that hardware as a target in your LabVIEW project. Writing VIs and debugging them happens on your Windows box and when you are confident that it works, you deploy the resulting compiled VI code to the target and let it run there. This so far only works under Windows. And porting that to a Linux host is a major undertaking that I'm not sure NI has invested any real effort into so far. Directly running the LabVIEW IDE on the Raspberry Pi is probably even more unlikely to happen any time soon.

I'm working through the same gauntlet. Had to manually install libglu1 before it would respond to the Applications selection. LV starts, but the tools and controls palettes just flash repeatedly. Installed on two machines running Pop!_OS COSMIC and both do the same, even though they are drastically different hardware. Did realize most of my old code has Windows dll hooks, so is of limited usage. Not sure how much I'm going to chase this at this precise instant in time. cheers

Thanks, I'll be honest, I'm allergic to Discord. Vehemently so. To the point where I refuse to use it. Just seems like a lot of unfiltered noise to this old man. I'm gonna play with NodeRed and see if it's the tool of choice. And oh, back in the day I was a National Instruments Alliance Member. Dunno if that's still a thing or not. Cheers,

I am a LabVIEW programmer professionally for the last 16 years. I also run Home Assistant in my house. It's great, but yeah the dashboard customization can be a bit hands on. I'd recommend their forums as well as facebook groups. They may have a Discord as well, but I've not joined that. I'd recommend not to attempt all of this in LabVIEW. While the automation logic might seem easier in your native language, the integrations alone are an incredible obstacle to rolling your own solution here. You may also want to look into HACS which is an alternate "app store" type extension for HA that allows for additional integrations and cards. Good luck!

Hello out there. Once upon a time in a land far, far away, I was a LabVIEW Partner (don't think it was Partner in those days, but that's what it's called now). As my professional activities drifted in a different direction, I've not done any LabVIEW in a while, but it's aways been near and dear to my heart. Life brought retirement about 2 1/2 years ago, and I've been dabbling with a number of things in my "spare" time. One of which is Home Assistant. Somehow, somewhy, HA has exploded as the thing in home automation. It's support of devices is amazing. There are some 10,000 "integrations" available and more being developed every day. The downside is the "programming" as they call it. Oi. I'm not a programmer, and don't play one on TV, but I'm conversant in a plethora of programming tools, including LabVIEW. HA purports to be able to do everything via it's UI, but the ugly truth is, the really useful screen elements (they call them cards) don't have UI connections. It's all YAML. (Yet Another Markdown Language) OMG. This stuff hurts my head in a spectacularly large and significant way. There are two "segments" to HA, Dashboards and Automations. Automations I can "kinda" do, but Dashboards are a nine line cluster. It took me over a week to build a simple UI with 5 screen elements to control the volume on three audio devices in my house. And that was with the help of some kind soul on the forum that took pity on me. Without his help, it simply wouldn't have happened. I could have crafted this in 20 minutes with LabVIEW, or python. So, what I have been doing is some automation stuff for the house. Due to my lack of knowledge of the ins and outs of automations, and the documentation is 12-24 months behind schedule at any point, I've had to break up what is effectively a state machine into about 10 discrete automations. And as you would expect, I'm running into issues with them interacting with each other. So, I've put together a textual descriptive of what I want to do and have been investigating the best way to do this in HA. What virtually everyone uses for these types of "flows" as they call them is NODE-Red. There is much to like about NODE-Red, but the first thing it reminded me of was LabVIEW. So, for laughs, this morning I went looking, and lo and behold found the Community Edition, and a version to run on Linux as a cherry on top. I'm migrating all my activities that I can away from Windows, as none of the computers in my house will run Windows 11. So, while I wait for NI to figure out why my e-mail is not verified, I have to ask: Has anyone had any interaction with HA? Any thoughts about interaction between LV and HA? Take care

labview 2025版本vi重写会闪退，好像是vi图标改变导致的，vi图标打开编辑也会闪退

Don't know if you guys noticed, LV Image to PNG Data creates an uncompressed png data while Write PNG File.vi creates a compressed png file. I'm using LabVIEW 2018 SP1 on Windows 10 Pro.

Nah. It was just an icon I generated for an Ollama client.

but not quite as punny... or am I just not smart enough to get that one?

The llama is cuter

Love the choice of embedded image 🙂

This is exactly what was said in that ancient thread: Tree control in labview. So if you add 65536*N to the Item Symbols property of the Listbox and have the "Enable Indentation" option activated, you shift the symbol/glyph and the text N levels to the right. Could be useful for simple 'parent-child' relationships, if you don't want to use a Tree. And still it's used in Find Examples / NI Example Finder window:

Hi all. A bit of nerdy fun if you can spare some brain cycles. I've written a Steganography API (0.9.0) and will be putting it on my site under a BSD-3 licence. It currently only uses the LSB method but I may do others if there is interest. I've optimised it as much as I can but I expect that better people than I can improve it's performance. So. The task is to make it as fast as possible. There is a benchmark with some images included so we can do comparative benchmarks. I'm looking forward to some innovative improvements. The winner gets a mention in the readme under SALUTATIONS. If you can find the time and/or inclination then please post your times for the vanilla installation and then after any improvements as shown below. Times to beat so far: LabVIEW 2009 x64, Win10 Before Modification: Encode: 297.9 ms Decode: 98.1 ms After Modification: Encode: 297.9 ms Decode: 98.1 ms Oh yes. And finally. If you find any bugs, let me know and I'll fix them.

hooovahh, all right,thank you for your better suggestion, later I wii do the test. I think it will be succeed definitely. Thanks a lot.

Instead of using a little Glyph image, it's a lot easier to set the background color of a cell in the result column.

David has posted to LAVA 1 time, and it was 10 years ago. I don't think he's going to respond. You cannot control the position of the glyph with the built in function. The only solution I know of is a pretty time consuming one, where you put a transparent picture control on top of the tree, and then you can do whatever you want. I've applied this to a sequence editor. The left and right are tree controls (as noticed by the collapsing icon). The tree on the right has two centered columns. This has two picture controls that position themselves to look like it is part of the tree. There's a decent amount of work on the back end to handle things like window resizing, collapsing the tree, and other random behaviors. But the end result is something I have full control of. Also in a related topic here is an idea exchange to support larger glyphs. There is a linked example on how to fake it in a fairly convincing way.

This still works. This is still a MCLB not a tree. I'm unsure if the feature exists for trees.

LabVIEW DSC does this with an internal tag name in the Control and the according configuration dialog allows to configure that tag name.

Hi David Koch, thanks for your reply, I have a question that how to make the glyphs to place center in cells?

Hi Hooovahh, Thanks for your answer. the vi's link of example is unreachable, and the picture that I uploaded is used tree control, also, I think multilistbox and tree control would use similarar way to achive multiple columns glyphs , but I don't have good thoughts right now, could you provide a better direction? the labview version that I use is 2020. Thank you again.