Fluid is a somewhat old app, but can be rather useful. It containerizes any website, making it into an “app” that you can put in the dock and assign to a desktop – things you can’t exactly do with a browser window. iOS has an analogous builtin functionality where you can add a web page to your home screen, but Apple hasn’t done this for macOS (yet). I have a number of Fluid Apps I use on a daily basis and I find them very useful.
After updating to Sequoia however, I was rather irked that Apple’s new security settings did not afford me the opportunity to say, “Hey, I’ve been using these apps for years. I created them. I trust them. I trust the Fluid app developer. Just let me run them.”
When I first tried to launch my trusty self-created apps, I would be presented with 2 cryptic errors:
(“RT” by the way, is the ticketing system we use at work to track user requests. When I’m on “RT duty”, I switch to my RT desktop and start handling tickets. I have a self-rolleddesktop-based time tracking system, so time I spend on that desktop goes toward my “RT Project”.)
I figured out a way around this irksome conundrum using code signing (which requires that you install xcode developer tools), but first, you have to remove what Apple now classifies as “detritus” with the following error if you try to code-sign an app that has things like resource forks:
$ codesign --force --deep -s - RT.app
RT.app: replacing existing signature
RT.app: resource fork, Finder information, or similar detritus not allowed
To remove the “detritus” and then code-sign an app (I’m using my RT.app), run the following in the Terminal.app:
Be aware that `xattr -cr` removes all the app’s newly Apple-disallowed attributes, which may brick the app? In my case, it didn’t seem to break anything, but if you want to see what it will remove, to understand what will happen, you can list the attributes with `xattr -lr RT.app`.
From now on, you should be able to launch and use the app!
It has been quite awhile since I’ve had any new blog posts, but I just fixed an issue with my Obi200 related to the recent ObiTALK shutdown on May 31st:
and I thought I would just throw up my rough notes on the process.
I’m not going to get into the details of that flow or how to modify it to reboot your Obi200, but I will say that basically, I have my Obi200 plugged into a smart outlet, which my flow power-cycles when it detects that the Obi200 has lost its connection. (I noted during this process that it may be possible to trigger a reboot using its API, but I didn’t try that.)
My flow stopped working sometime around May 31st. That’s because MrTom’s flow was looking for a substring in the status xml file that was related to the ObiTALK status (“Normal (User Mode)”) instead of the google voice connection status. My Obi200 continues to work with google voice. (There’s just no way to (easily) reconfigure it if the GV account ever changes.) I debugged the issue on the command line using this curl command:
Note that you have to use --digest or you get a 401 error response. Adding --digest actually initially responds with another 401, but curl apparently makes a second request that succeeds. Not sure what that’s about.
This is the relevant section of the output:
<object name="SP1 Service Status" access="readOnly" minEntries="0" maxEntries="4" numEntriesParameter="NumberOfLines" enableParameter="Enable" subtitle="SP1 Service Status" status="true" notify="true" > <parameter name="Status" provision="false" access="readOnly" > <description > Status of this service </description> <syntax > <string > <size maxLength="128" > </size> </string> </syntax> <value hash="f84a7e6" type="input" default="" current="Connected" >
The thing to look for to determine the google voice status is the xml element named “SP1 Service Status” (“service provider 1”) and its contained value element’s “current” attribute (“Connected”). There are 4 possible service provider status elements. I have 2 configured and according to google, “SP1” is (likely) google. I don’t actually know what my SP2 slot is configured for. I thought all I had was google voice, so I suggest exploring your 4 slots to see what slot is related to your desired provider whose status you want to monitor.
The connected status of my SP1 provider is confirmed on the obi200’s web interface. Once you log into the device using it’s IP address, the SP1 status can be found on the system status page:
That json element path may be different in your setup/Obi firmware version. You can explore the path from the beginning using a debug node and changing the value to output using each step of the msg path from msg.paylod to msg.payload.model.object[4].parameter[0].value[0].$.current
Useful obi info I found when looking into this:
The ObiTALK portal, which was used to set up OBi devices with Google Voice, has been shut down as of October 31st, 2024. Therefore, you cannot manually connect your OBi200 to Google Voice using the traditional OBiTALK setup method.
Important Information:
Discontinued Support: All OBi devices that worked with consumer Google Voice have been discontinued by HP/Poly.
No New Setups: You cannot add, remove, or configure consumer Google Voice service on OBi devices through the ObiTALK portal.
Existing Devices May Still Work (for now): If your OBi200 was already configured with Google Voice before the ObiTALK shutdown, it may continue to function for an undetermined period.
No Alternative Direct Setup: There are no other devices from any manufacturer that work directly with consumer Google Voice, and there are no plans to change this.
What You Can Do:
Since direct manual setup through ObiTALK is no longer possible, you will need to consider alternative options:
If your OBi200 is already configured with Google Voice: You can continue to use it as long as it works, but be aware that support is limited.
If you need a new VoIP solution: You will need to explore other VoIP providers and devices that offer compatible features with your needs. Some providers may offer SIP credentials that allow you to connect your OBi device, but this would require configuring the device directly through its web interface, not the ObiTALK portal.
Migrate to a different service provider: Providers like Anveo may offer alternative methods to connect your OBi device using SIP credentials.
In summary, it is no longer possible to manually connect an OBi200 to Google Voice using the ObiTALK portal due to its shutdown. You should explore other VoIP options or verify if your already configured OBi200 is still working.
Always with you what cannot be done 